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[57] ABSTRACT 

Disclosed are a method and apparatus for collecting network 
data from a computer network. Control structures are created 
for groups of data to be collected. The control structures are 
then associated with corresponding tables for storing the 
data. Different control structures and extract functions are 
defined depending upon which data is to be collected, and 
the form in which the data is to be presented. These control 
structures and extract functions are then employed to avoid 
redundant data gathering efforts. 

20 Claims, 8 Drawing Sheets 
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NETWORK DATA COLLECTION METHOD should be gathered and available to the network. Software 

AND APPARATUS developers can then write their applications, knowing that 

any system which complies with the standard will provide 
This application is a file-wrapper continuation of appli- this data. These type of standards, among other things, 
cation Ser. No. 08/1303 17, filed Oct. U 1993, now aban- 5 facilitate the development of distributed network manage- 
doned. ment 

^ ^ Within SNMP, RMON MIB was developed as a standard 

FIELD OF THE INVENTION management information base ("MIB"). It will be appreci- 

The present invention relates to computer network man- m ated a MIB is a collection of data and that a MIB is in 
agement and, in particular, to collecting network data with 10 no wa ? limtel t0 RM0N specification. For an Ethernet 
a scalable data engine. segment, RMON requires nine groups of data: Statistics 

Group; History Group; Host Group; Host TopN Group; 
BACKGROUND OF THE INVENTION Matrix Group; Alarm Group; Filter Group; Packet Capture 

Group and Event Group. This set of data is then available to 
Computers are commonly arranged into networks to allow 15 the network management platform or other application. For 
intercommunication. Depending upon the interconnection i0 ^ n rmoN requires ten groups, the nine outlined 
technology, these networks can span great distances. above plus a token ring group. 

Moreover, the networks can employ one or more commu- SNMP effectively defines the network as a world full of 
mcataon protocol^devices may be added or removed from obj each a ^ ^ SNMp does ^ 

the network arbitrarily, c—nication paths may change, 20 instnJct how this ^ ou ^ t t0 be colle cted and compiled, 
and the nature and characteristics of the network traffic is 5^^^^^^^^^, as itisknownin 
vanable. As such, the management of these systems has ^ ^ 

become increasingly complex. . 

, . . . „ Basically, this newer architecture has a plurality of dedi- 

Among other things, network management typically cated nodes kced ^ hout ^ network ^ of toe 

entails dctenrnmng which sections of a computer network 25 dedi ^ tedn ^ sis con ^^ 

are over- or under-utilized. In addition, it includes detecting corresponding network segment ^ process of gathcring 

and locating network fault. i so thatrepairs and/or re-routmg is ^ .^.p^ updating." In such a 

of the network can be made, if necessary. proces$) me dedicated Dode receives ^ packet mat passes 

In order to perform these network management functions, the node and analyzes the packet in order to update corre- 

network management tools have been developed to assist the 30 sponding data structures, typically tables. For example, if 

MIS expert in managing the network. Network management SNMP is used on an Ethernet and if SNMP is using a 

tools employ software applications that allow the MIS RMON-like MIB, the per-packet update would need to 

expert to diagnose the network and thereby minimise main- update the data structures corresponding to the nine groups, 

tenance cost by efficiently utilizing the MIS expert's time. M some ^ thc QCtwork management tool will likely 

Sometimes, these tools include dedicated hardware. rcqucst ^ ^ from ^ dedicatcd nodes. For example, it 

Some older network management tools performed these may request this data to display it in graphical form, or it 

tasks by periodically polling certain devices connected to the may request this so that it can perform some further data 

network. A device connected to the network is commonly analysis. In any event, SNMP requires that the data be 

called a network node, or just node. This approach is ^ available for external query. The network management tool 

sometimes referred to as the "piag" approach. Though this communicates with the dedicated node, for example by 

approach could determine connectivity and operability of SNMP, by requesting the particular data, 

the nodes, it could not effectively provide the full range of rtds newer architecture of using dedicated nodes and 

functionality that network professionals desired. For communication protocols implicitly demands that the dedi- 

example, it was impractical for these systems to gather 45 cated nodes have a very ^ network performance. Typi- 

utili2ation statistics, and connectivity analysis is only a ^ me dedicated node needs a network performance an 

small portion of the task of isolating network problems. order of magnitude higher than a "normal" node. This is so 

Later, protocol analyzers were developed, which provided because the dedicated nodes must be able to process aggre- 

the capability of collecting basic statistics and filtering for gate network traffic, whereas a normal node typically needs 

and decoding of specific packets. It will be appreciated that 50 to handle bandwidths associated with typical network com- 

the structure of a packet will depend upon the underlying munications. If a normal node gets congested, it can typi- 

protocol. However, protocol analyzers require a technician cally rely upon standard retry algorithms, known in the art, 

to take equipment to the problem, once it is discovered. to ensure that it will eventually get the packets intended for 

Still later, network management tools used dedicated it. On the other hand, if the dedicated node gets congested, 
nodes to monitor all of the network traffic passing the node. 55 any missed packet would go unproccessed because when the 
These dedicated nodes used embedded systems, i.e., micro- dedicated node is operating passively and promiscuously it 
processors and memory storing task-specific software, to should not request a retry. It will be appreciated that the 
monitor network traffic passing the node. By judiciously underlying network protocol defines the process for reject- 
placing these nodes into different network segments, the ing and retransmitting packets. 

tools could gather information about all of the network so In order to meet these stringent performance 
traffic. These systems provide more functionality, but have requirements, the prior art used dedicated nodes having 
stringent performance requirements, as they require the node embedded systems, which relied upon in-line programming 
to handle all network traffic passing the node. for the microprocessors. It was thought that in-line program- 
Standards, such as SNMP, were eventually developed to ming was necessary to meet the stringent performance 
facilitate development among different network manage- 65 requirements. Essentially, in-line programming is a single 
ment software suppliers (SNMP: Standard Network Man- stream of code (i.e., program instructions) with no jumps, 
agement Protocol). SNMP outlines what statistical data procedure calls, function calls, or other breaks in the control 
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of the code. As such, in-line code quickly becomes electronic signals on the network into a digital form, a 

cumbersome, complex, and difficult for a software engineer memory for storing the digital form, and a CPU for pro- 

to understand. cessing the digital form in accordance with software mod- 

In the context of network management tools, multiple uks stored in the memory, the softwa rejn ftdules includ ing 

tables of information in a memory unit usually need to be 3 a scalable network d a ta engine that is independent of the 

managed. Often this management contains a certain set of n etwork protocol' or m*e compute r network and whereinth e 

common operations associated with each table and a certain net work data engine is executed by me cFCT to provide the 

set of unique operations associated with each table. With functionality for creating ana deleting tables within the 

in-line programming, however, even the common operations memory, updating table entries within the tables, insertin g 

must be reiterated at each instance of the management of 10 an d deleting entries fx om the tables, and searching the tables 

each table. If a programming bug is present within the according to a plurality , of indices, 

common operations, this programming bug will be present Within this description, reference to the network data 

at each instance, Le M for each table. In contrast if a engine providing some function is to be understood as the 

procedure or function is used for the common operations, the CPU executing the network data engine so as to provide that 

bug will have only one instance. 15 function. 

Moreover, it is highly likely that the code will need to The network data engine further provides a base set of 

imdergosubsequentrevisions.m-Hne programming requires table functionality and provides a mechanism for calling 

that the programmer decipher the in-line code to discern the routines external to the network data engine but residing 

exact code fragments that need updating. Similarly to that within the memory. As such, a network application that 

described above, this update will need to be done at each 20 needs tables need only supply code that is specific to the 

instance, in contrast to a single instance if procedures and individuality of each table and need only supply certain 

functions are used. This is especially complex in prior art information concerning the tables to the network data 

systems as in-line programming is non-modular, and the engine. It will be appreciated that the particular application 

programmer will have to be wary of protocol sensitive code. can correspond to SNMP or to any other application that 

Dynamic module loading, which has been used in other 25 ncc ds a plurality of tables, 
contexts, such as Microsoft Windows* Dynamic Linked The tables upon which the network data engine operates 
Libraries, may be very useful for a dedicated node. For will likely include the tables required by the network man- 
example, such dynamic loading can be helpful for imple- agement protocol being used by the network. However, the 
menting a sophisticated version and release control, in 3Q tables can also include general purpose tables, 
which different network segments can have different com- As new network standards are developed, the dedicated 
binauons of the software. For example, one segment of the flode utilizing the present invention can be easily updated 
network may need a particular application, such as a proxy and ported, as the data engine is independent of the protocol 
manager or an accounting package, that the other network and operates on tables only generally and is not table 
segraents do not need. Dynamic loading allows the different 35 specific. As such, a new protocol, requiring new tables, can 
combinations of software residing on the various segments use me network data engine without revision. An implemen- 
to be tailored to the system s needs. Dynamic loading also 0 f a new protocol need only include new codefor each 
benefits the software distributor, as it will not need to re-link new table's specific individuaHty. 
the various software combinations in order to release them . . . . 

(Linking and re-linking software are known in the art). In M t . ^ ^ Jfl P T?k \* m ^ SI \ for f owm 8 

addition such loading is also helpful for implementing 40 basc ? - J**™ ^ch table and allows for dynamic 

transient diagnostics. Dynamic loading is extremely difficult loatUng of modules mto * e memor y of me ^^dnode. 

to implement with an in-line program technique because the BRIEF DESCRIPTION OF THE DRAWING 
new code will need to be concatenated with the existing code 

and any new code will need to employ some form of invention will become more apparent from the fol- 

memory address independence (e.g., self -relative lowing detailed specification and drawing in which: 

addressing) to ensure operability. Though such a process is FIG. 1 illustrates a network segment; 

theoretically possible, the high level of difficulty for doing HG. 2 illustrates a software module architecture for a 

such a task will be appreciated by those skilled in the art dedicated node having the present invention; 

All in all the prior art systems with their use of in-line 50 FIG. 3 illustrates a preferred embodiment of the software 

programming greatly add to development costs and times by modulc architecmre of the present invention; 

requiring more sophisticated programmers to understand the CTO A .„ . . ~ . . , 

comply non-modular code J^ 0, 4 mustr ^ * software architecture for a RMON 

In connection with this, one can expect that new network ™L - . ^ , 

management standards will be developed in the future. It is 55 HG ' 5 r mustrat f m ? ow chart form the per-packet update 

likely that these standards will require more sophisticated F 00 ™ for a P referred embodiment of the invention; 

statistics and the like. The prior art approach requires that a * is a top level process model of a dedicated node; 

new in-line program be developed for each new standard. FIG. 7 illustrates in flow chart form the periodic updating 

This greatly adds to the development cost and greatly performed by a preferred embodiment of the invention; and 

increases the implementation time. ^ FIG. 8 illustrates a control structure used by a preferred 

SUMMARY OF THE INVENTION embodiment of the invention. 

-Tha^hnrtrnt^f nf th* pg OC art are overcome a nd other DETAILED DESCRIPTION 

object s aye acco mplished with a system empioymgTsu ffi- FIG. 1 illustrates a network section 10 of a computer 

dcnrn u iriber nf net work nodes-x o nnected throug hout^ a 65 network. A communication cable 11 interconnects the vari- 

coTnputer-nr.fa/nrlr adapted to collect network data, w herein ous network nodes 12. Each network node 12 can typically 

each such node has a network interface to translate the operate autonomously. However, often these nodes 12 coop- 



08/28/2002, EAST Version: 1,03.0002 



5 ? 634 ? 009 

5 6 

crate to perform a large task by distributing the work among event and timing services, process management, I/O 
the various nodes. Though the figure illustrates a network services, and numerous device drivers and the like. In a 
section only, it will be appreciated that such segments can be preferred embodiment operating system 21 is optimized to 
arranged in various network topologies, such as rings and maximize network packet throughput, 
trees, and that the various segments will likely employ a 5 System manager 22 provides a number of ancillary 
probe 13. A probe is a network node, dedicated for network services, such as configuration and module loading, a corn- 
management, and is further described below. ma nd line interface, and an interface to serial line access. 

la order for one node 12a to communicate with another The RMON MIB 23 is a management information base, 

node 12fc, the communication will occur via cable 11. Node For example, the RMON MIB for the Ethernet has nine 

12a will transmit apacket, which will include as a target the io &mps (see above)t Briefly re f e rring to FIG. 4, each group 

address of 12fc. Node 122> monitors the cable and detects that 0 f foe MIB may be split into a MIB module 41 and a data 

the packet is intended for itself by recognizing its address. collection module 42. The MIB module 41 contains routines 

It will be appreciated that many network protocols allow a ^ ^ structures required to represent the corresponding 

broadcast-type communication in which more than one node to t>i e ^ fo e gr0U p i j^t table-specific routines, such as the 

will receive the conimunication. It will also be appreciated 15 extract and update rout in es w hich are described below, are 

that the numerous protocols for gaining access to cable 11 as storc 4 in me ^ collection module. It will be appreciated 

well as for transmitting the network packet are known in the ^ by storing rou tines in the data collection module the 

art and that the description above is informational only. network data engine remains independent of these routines. 

These protocols will not be further described herein for the ^ pj- ocess f or updating the corresponding tables will be 

sake of clarity. 20 fm±tr & scyissed bclow> It will be appreciated that different 

In a preferred embodiment, probe 13 utilizes an Intel MIB architectures may be utilized by the invention, and for 

8G960CA RISC CPU, indicated as 14, 4 MB of memory 15, that matter, the invention is not limited to the RMON MIB. 

and the 82596CA LAN interface 16. The several software By way of example, SNMP RMON MIB requires a matrix 

modules, described below, executed by CPU 14 are written ^ essentially contains information concern- 

primarily in the C programming language, for example, and 25 * mg ^ numerous conversations occurring on the network 

may operate under an operating system residing in memory segment. It contains data such as the network addresses of 

15 that provides UNIX-like functionality. me communicating nodes and the associated byte count and 

Probe 13 operates in a passive and promiscuous mode in packet count between the communicating nodes. Moreover, 

which it monitors all packets transmitted on cable 11. The it organizes this data for each direction of the conversation. 

LAN interface 16 translates the electronic signals transmit- The group further specifies that the key for accessing data 

ted on cable 11 into digital form and stores the digital form corresponding to this group is the pair of communicating 

in memory 15. Then, CPU 14, executing the software node addresses. In other words, if an application needed the 

modules described below, operates upon this digital form. information described above, it would request that data by 

Though the description herein refers to the probe as being 35 requesting data from the Matrix group and by providing a 

a dedicated node, it should be appreciated that this is for key, comprising the network addresses it was interested in. 

convenience only. Far example, the present invention may It will be appreciated that this description of the RMON 

be employed in a router and still perform its data collection. MIB Matrix group has been simplified for descriptive pur- 

Moreover, though the description refers to the probe as poses. Further details about the group are not necessary to 

receiving all packets passing on the network, it will be ^ understand the present invention. 

appreciated that the present invention is not precluded from SNMP module 24 includes the necessary software for 

an application that operates on a subset of the packets only. communicating in accordance with the SNMP protocol. For 

As will be further described below, probe 13 analyzes example, if SNMP data is requested from the probe, the 
each packet, ie. , the digital form residing in memory 15, to SNMP module will decode the request. As will be more fully 
determine whether the packet is intended for itself. For 45 described below, this will include decoding the request into 
example, another node may request certain information from a table name and key which will then be used to retrieve the 
probe 13. If a packet is targeted to probe 13, probe 13 will data from the corresponding table. In addition, SNMP mod- 
respond accordingly, i.e., like a normal node. If the packet ule is responsible for initializing certain aspects of the 
is not intended for probe 13, Le., the target address is not that network data engine 25. As previously stated, network data 
of probe 13, probe 13 analyzes the packet in order to update 50 engine 25 operates on data tables only generally. Thus, 
certain tables within memory 15. For example, RMON MIB, SNMP module 24 must pass certain information to network 
a MIB for SNMP, outlines what data should be accessible data engine 25 so that network data engine 25 can create the 
and how. As such, if the probe 13 is used in an SNMP appropriate tables and gather an understanding about the 
RMON MIB environment, RMON MIB will determine a tables for which it is responsible for updating. This is 
minimum set of tables, which probe 13 must keep and 55 achieved by the SNMP module 24 passing information 
manage. As was previously described this process is called which will be mirrored in a control structure located within 
per-packet updating and will be further described below. the network data engine 25. in particular within the alloca- 

A network management tool, residing on one or more tion services (see FIG. 3). This control structure is created 

nodes of the computer network, can then access these tables dynamically. Each table will have its own control structure, 

by communicating certain instructions to probe 13. These 60 Moreover, each table is created dynamically by the data 

instructions are defined by the underlying protocol, e.g., engine 25 and is "owned" by the data engine. 

SNMP. As was described above, probe 13 will recognize the Even though FIG. 2 illustrates module 24 as an SNMP 
packet containing the instruction as intended for itself and module, it will be appreciated that this module can be 

respond accordingly. replaced by any application that needs to manage tables. For 

FIG. 2 illustrates the software module architecture of 65 example, if a new network management protocol were 
probe 13. Operating system 21 provides a number of basic developed, the new application would replace SNMP 24 and 

operating system functions, such as memory management, would need to pass the necessary data to network data 
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engine 25 so that data engine 25 could construct the appro- (see also 58, FIG. 5). In addition, it will also perform 

priate control structure. collision handling, for example if two keys hash to the same 

It will be appreciated that, though the following descrip- table entry (see also 58, FIG. 5), Collision handling and table 

tion uses the terms "structure*' and ''function" in similar management are known in the art. 

fashion to that of the C prograinming language, other 5 The network data engine core 31 also calls an initfunction 

hmguages employ different terminology to describe similar 95 Mtd t0 b thc control stnicturc 80 whcncvej a ncw 

fadhues and that the present invention is in no way limited ^ entr ^ ^ ^ L whenever it h ^ to of 

toapato^pn&^glM^ akey(seealso59,nG.5).Ifmepackethaderrorstatusit 

Referring to FIG. 8, each table has a control structure 80 u u {:^ v ihat A _ am1l > at : rtn w ™m ™f„. ^ nni r.™n«c *w 

matmdudesmefoUowmg:*^ w *JK e ^^ 

allow for the table 81; the size of each row 82; the offset W ***** J^^J^Z I then include the appro- 

fromthebaseof the row to a hash key 83; the size of the hash P mtc codc t0 abort **** P«>«™8 for mis table, 

key; the number of slots in the hash table 85; a pointer 86 to Lastly, the core 31 also calls an update function pointed 

the base of a hash table 87; an array of directory descriptors t0 bv *e per-packet update structure 91A (see also 60, FIG. 

90; an array of per-packet update structures 91, which are 5). This function usually contains the "guts" of per-packet 

described below; a pointer 92 to a first stage hash function 15 updating. Again, this function, like those described above is 

92; and pointer 94 to an init function 95. application specific, and the data engine 25 remains inde- 

Each per-packet update structure 91A includes an extract pendent of it 

function 96 and an update function 97. These functions will It will be appreciated that this process is independent of 

be further described below. Other items included in the the underlying protocol, e.g., SNMP, as the control loop 

control structure will be described below. 20 operates on the various tables only generally and calls 

Each control structure 80 includes an array of directory external routines to handle the peculiar aspects of the 

descriptors 90. as stated above. A directory 98 is a group of particular table. 

additional indices sorted according to a key. Accordingly, The upcall interface 33 handles the external function 

every time an entry is added or deleted from the associated ^ calling, referred to above. The allocation services 35 allows 

table, the directory needs to be resorted. As was discussed the creation and deletion of network data engine tables, and 

above in the summary of the invention, the particular the ability to activate or suspend existing tables. Tables arc 

application may require one or more directories for a group. usually created at initialization and can be deleted, if ncc- 

For example, in thc Matrix group, two directories are essary. 

needed. The key will be the pair of addresses, and there will 3Q Table access and manipulation services 34 allow the 

be one directory corresponding to each direction of com- underlying application, e.g., the SNMP application, to 

munication. Again, the use of directories will depend upon access the data that is being collected Each table can be 

the underlying application. accessed using any one of its indices. This section is also 

As previously mentioned, network data engine 25 is responsible for table entry insertion and deletion as 

responsible for updating the various tables on a per-packet 35 requested by the associated application, ie., SNMP. The 

basis. FIG. 3 illustrates the software structure of network indices automatically recalculate after each insert and delete 

data engine 25. FIG. 5 shows a flow chart describing the operation. For example, an insertion will occur when the 

per-packet update process. The network data engine 25 will probe receives a packet from a node for the first time, 

be described by referring to these figures jointly. Data entr y core 31 provides synchronization for the 

Packet input section 32 receives all network packets that ^ tables. This is necessary because the tables need read and 

pass probe 13 (see also 51, FIG. 5). These packets are then write access from multiple sources, such as during per 

passed to data engine core 1. Upon receiving a packet, data packet updates and from SNMP requests. Synchronization 

engine core 31 loops through each table that is marked methods are know in the art, and will not be further 

"active" (i.e„ tables may be suspended from per-packet discussed herein other than to state that, in a preferred 

updating). For each active table, the data engine core 31 45 embodiment, the network data engine 25 operates at a 

loops through the array of per-packet update structures 91 process level higher than the associated application, i.e., 

(see also 53, FIG. 5). SNMP, 

Within the loop, i.e., the loop corresponding to the per- Since network data engine 25 is independent of the 
packet update structures, the network data engine extracts a particular protocol, the functions for operating on the van- 
key from the packet by calling the extract function 96 50 ous tables are independent of the protocol, as welL As such, 
pointed to by the per-packet update structure 91A (see also the network data engine 25 can be used for general purpose 
54, FIG. 5). tables used by the various software modules. Moreover, 

If the extract function fails to find a key, for example network data engine 25 is easily ported to future protocols 

because the packet is too short or because the packet is and different revisions of an existing protocol, which will 

corrupt, the data engine core 31 aborts this update and 55 require different tables. 

proceeds to the next per packet update (see also 55. FIG. 5). FIG. 6 illustrates the various software mechanisms of 
If a key is found, the data engine core 31 calls a first stage probe 13, displayed as a top level process model. Some 
hash function 93 pointed to by the control structure 80 (see abstraction is present for the sake of clarity. This is an 
also 56. FIG. 5). This hash function 93 preferably is matched alternative way of describing the software architecture. The 
to the nature of the data that is stored within that table. Hash 60 several software processes correspond to the several mod- 
functions desirably provide an even distribution of hash ules previously discussed, with minor variations. LAN pro- 
numbers given a distribution of keys. A second stage of cess 64 handles the network interface. Every time LAN 
hashing is performed by the network data engine itself to process 64 receives a packet it calls network data engine 25 
insure that the resulting address will fall within the corre- and passes the corresponding packet with associated status 
sponding table (see also 57, FIG. 5). 65 to the network data engine 25, The network data engine 25 
The network data engine core 31 will perform necessary is embedded within the LAN process 64, and both operate 
table management, such as inserting a new entry if necessary at Kernel priority level, in a preferred embodiment 
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The network data engine then operates as described 
above. Probe 13 operates in a promiscuous mode, listening 
to all traffic passing the probe. However, it also receives and 
transmits packets in similar fashion to other network nodes. 
If a packet is addressed to the probe, Le., the target address 5 
of the packet corresponds to the probe address, LAN process 
64 passes the packet to network process 65, assuming that 
there are no errors. Network process 65 then either passes 
the packet up through the various network protocol layers or 
rejects the packet For example, if the packet is SNMP io 
related the packet will be passed to SNMP process 66. 
SNMP process operates at a priority level lower than the 
LAN process 64, in a preferred embodiment. This process is 
similar to other network processes known in the art 

Processes 66-68 are similar to the corresponding modules 15 
discussed in relation to FIG. 2, and their description will not 
be repeated herein for the sake of clarity. 

The process model illustrated in FIG. 6 is helpful for 
describing the dynamic software environment of probe 13. 
This environment allows a dynamic loading of modules. As 20 
such, a dynamically loadable module ("DLM") 69 can be 
transmitted to probe 13, via known file transfer protocols. As 
such, operating system 21 (see also FIG. 2) will manage 
DLM 69 in addition to the processes already discussed. It is 
loaded by system manager 69, as previously stated This 25 
dynamic loading of processes is known within the computer 
field, but has primarily been used in different contexts. For 
example, Microsoft allows dynamic loading via its Dynamic 
Linked Library and UNIX allows such loading via its 
"Shared Library" utility. Previously, this was impractical far 30 
prior art dedicated nodes. 

Moreover, the process model displayed in FIG. 6 makes 
is easier to understand the network data engine in relation to 
the operating system and the other processes. For example, 3J 
the present invention can perform table updates periodically. 
Periodic updates can be performed by calling the appropriate 
update functions in a timed fashion. Consequently, time- 
based statistics can be easily implemented. For example, 
response times for packets can be determined by time- ^ 
stamping when a request was sent out and noticing when a 
response was received. It is important to note that SNMP 
does not suggest or require such statistics. 

In order to perform such time-based statistics, the control 
structure 80 (See FIG. 8) described above also includes a 4 « 
record number index 88 which in effect is an insertion order 
index. This points to all the valid table entries, but does not 
require the overhead of using keys. Thus, it provides for 
faster response in bulk-type transactions. 

The control structure also includes an array of rank so 
descriptors 99. a rank 100 being a table of indices sorted by 
a particular key and updated periodically. As such, they are 
somewhat akin to directories, but again, directories are 
updated on insertion and deletion of entries. The control 
structure 80 also points 101 to a periodic update function 55 
102 that is called once per time interval far each row in the 
table. In a preferred embodiment the time interval is one 
second. The network data engine 25 then loops through each 
active table and calls the periodic update function for each 
valid table entry pointed to by the record number index. It ^ 
will be appreciated that this process allows the underlying 
application to calculate time-based statistics or to trigger 
some other time-based activity. 

FIG. 7 illustrates a flow chart describing the periodic 
update process. Referring to FIG. 7 and 8 jointly, at every 65 
time interval 71 the network data engine will loop through 
each table determining whether the table is marked active 72 
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(See also 99, FIG. 8). If the table is marked active the 
network engine determines whether a periodic update func- 
tion (See also 102, FIG. 8) is present for that table 73. Then, 
for each row pointed to by the record number index (See 89, 
FIG. 8), which in turn is pointed to by the control structure 
74, the network data engine calls the periodic update func- 
tion pointed to by the control structure 75. This periodic 
update function is passed the time delta 103 since the last 
update in addition to a pointer to the table entry, so that the 
function can perform accurate time-based statistics. This 
time delta is necessary to compensate for inaccuracies that 
might otherwise occur as a result of new table entries, etc. 

Having thus described several particular embodiments of 
the inventions, various alterations, modifications, and 
improvements will readily occur to those skilled in the art 
Such alterations, modifications, and improvements as are 
made obvious by this disclosure are intended to be part of 
this disclosure though not exclusively stated herein, and are 
intended to be within the spirit and scope of the invention. 
Accordingly, the foregoing description is by way of example 
only and is not intended to be limiting. Hie invention is 
limited only as to find the following claims and equivalents 
thereto. 

What is claimed is: 

1. A method of collecting network data from a computer 
network at a remote node having a processor, an operating 
system, a network protocol module for communicating on 
the network in accordance with a predefined protocol, a 
management information base arranged in accordance with 
the protocol and having tables for storing the collected data 
and having corresponding functions for each table including 
a periodic update function and a network data engine, the 
method comprising the steps of: 

(a) the network protocol module providing a description 
of the management information base to the network 
data engine, including providing a description of the 
tables and providing a pointer to the corresponding 
periodic update function; 

(b) the network data engine receiving the description and 
constructing therefrom a control structure for each 
table; 

(c) after step (b), the network protocol module monitoring 
the network and reciveing all packets passing there- 
through; 

(d) upon receiving a packet, the network protocol module 
passing the packet to the network data engine; 

(e) the network data engine processing the packet in 
accordance with the control structure for each table; 

(f) at predetanined intervals, the network data engine 
calling the periodic update function for each table to 
update the table in accordance therewith; and 

(g) the network protocol module providing a record 
number index pointing to an index, the index having 
indices listed in the order of insertion of table entries of 
the tables. 

2. A method of collecting network data from a computer 
network at a remote node having a processor, and operating 
system, a network protocol module for communicating on 
the network in accordance with predefined protocol, a man- 
agement information base arranged in accordance with the 
protocol and having tables for storing the collected data and 
having corresponding functions for each table, including a 
periodic update function, and a network data engine, the 
method comprising the step of: 

(a) the network protocol module providing a description 
of the management information base to the network 
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data engine, including providing a description of the 
tables and providing a pointer to the corresponding 
periodic update function; 

(b) the network data engine receiving the description and 
constructing therefrom a control structure for each 5 
table; 

(c) after step (b) t the network protocol module monitoring 
the network and receiving all packets passing there- 
through; 

(d) upon receiving a packet, the network protocol module 10 
passing the packet to the network data engine; 

(e) the network data engine processing the packet in 
accordance with the control structure for each table; 

(f) at predetermined intervals, the network data engine 
calling the periodic update function for each table to x $ 
update the table in accordance therewith; and 

(g) the network protocol module providing an array of 
rank descriptors, cash rank descriptor pointing to a 
rank, a rank being a table of indices sorted by a 
corresponding key, and wherein step (f) updates the ^ 
table via a rank. 

3. A method for collecting network data from a comput- 
erized network, the method comprising the steps of: 

(a) creating, for a plurality of groups of data intended to 
be collected from the network, a respectively corre- 
sponding plurality of control structures; 25 

(b) associating the plurality of control structures with a 
respectively corresponding plurality of tables, the plu- 
rality of tables being adapted to store the plurality of 
groups of data; and 

(c) storing, for each one of the plurality of control 30 
structures, in an associated one of the plurality of 
tables, a respectively corresponding one of the plurality 

of groups of data based on a network packet received 

from the computerized network, 
wherein a first set of control structures of the plurality of 35 
control structures is associated with a first management 
information base defining a first set of groups of data of the 
plurality of groups of data, and wherein step (c) includes a 
step of; 

calling, for each one of the first set of control structures, 40 
functions of the first management information base 
to update a first set of tables of the plurality of tables, 

and wherein a second set of control structures of the 
plurality of control structures is associated with a 
second management information base defining a 45 
second set of groups of data different from the first 
set of groups of data, and wherein step (c) further 
includes a step of: 

calling, for each one of the second set of control 
structures, functions of the second management 
information base to update a second set of tables of 50 
the plurality of tables, 

and wherein the functions include a first extract func- 
tion and a first update function, wherein the first set 
of tables includes a first table, and wherein the step 
of calling includes a step of: 55 

invoking the first extract function to extract a first key 
from the network packet, and the first update func- 
tion to update the first table according to the first key, 

and wherein the functions further include a second 
extract function and a second update function, 60 
wherein the first set of tables further includes a 
second table, and wherein the step of calling further 
includes a step of: 

invoking the second extract function to extract a second 
key from the network packet, and the second update 65 
function to update the second table according to the 
second key. 



4. The method of claim 3, wherein the step of calling 
further includes a step of: 

invoking the second extract function to extract a second 
key from the network packet, and the second update 
function to update the first table according to the 
second key. 

5. The method of claim 3, wherein the first table includes 
a plurality of rows respectively identified by a plurality of 
keys, and wherein the step of invoking includes a step of: 

updating one of the plurality of rows respectively identi- 
fied by the first key. 

6. The method of claim 5, wherein the step of calling 
further includes a step of: 

invoking, when initially none of the plurality of rows is 
respectively identified by the first key, a create function 
to insert and initialize a new row respectively identified 
by the first key, in the plurality of rows of the first table. 

7. The method of claim 3, further comprising a step of: 
accessing at least one of the plurality of tables to retrieve 

at least one of the plurality of groups of data. 

8. The method of claim 7, wherein the plurality of tables 
are sorted in a first order and a second order, and wherein the 
step of accessing includes a step of: 

retrieving the at least one of the plurality of groups of data 
in the first order in response to a first command, and in 
the second order in response to a second command. 

9. The method of claim 3, further comprising a step of: 
periodically storing, for a periodic structure respectively 

corresponding to a periodic table, time based statistics 
of the computerized network. 

10. The method of claim 3, wherein the plurality of 
control structures is arranged as a linked list of control 
structures, and wherein step (a) includes a step of inserting 
a control structure into the linked list. 

11. The method of claim 3, wherein the plurality of 
control structures is arranged as an array of control 
structures, and wherein stop (a) includes a step of adding a 
control structure to an end of the array. 

12. A system for collecting network data from a plurality 
of groups of data in a computer network through which 
network packets flow, comprising: 

a plurality of control structures, each control structure 
corresponding to a group of data from the plurality of 
groups of data; and 

a plurality of tables associated with the plurality of control 
structures, the plurality of tables being adapted to store 
the plurality of groups of data; 

wherein for each one of the plurality of control structures 
a respectively corresponding one of the plurality of 
groups of data based on the network packet received 
from the computerized network is stored in an associ- 
ated one of the plurality of tables, and 

wherein a first set of control structures of the plurality of 
control structures is associated with a first management 
information base defining a first set of groups of data of 
the plurality of groups of data, and wherein for each 
one of the first set of control structures, functions of the 
first management information base are called to update 
a first set of tables of the plurality of tables, and 

wherein a second set of control structures of the plurality 
of control structures is associated with a second man- 
agement information base defining a second set of 
groups of data different from the first set of groups of 
data, and wherein for each one of the second set of 
control structures, functions of the second management 
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information base arc called to update a second set of initially none of the plurality of rows is respectively iden- 

tables of the plurality of tables, and titled by the first key to insert and initialize a new row 

wherein the functions of the first management information respectively identified by the first key in the plurality of rows 

base include a first extract function and a first update of the first table. 

function, wherein the first set of tables includes a first 5 i& The collection system of claim 12 wherein at least 

table, and wherein function calling includes invoking onc of ^ plurality of tables is accessed to retrieve at least 

the first extract function to extract a first key from the one of ^ plurality of &oa ps of data, 

network packet and the first update fimction to update ^ ^ of ^ M wherem &e 

the first table according to the first key, and , t . - .. . . ^ * t . , 

. r jo plurality of tables are sorted in at least first and second 

wherein the tactions of the second mamgement infor- Qlders and wherein at least one of ^ lurality « n s of 

mation base include a second extract function and a . A . ■ . _ _ , _ , . T ^ 

second update function, wherein the first set of tables ^ ™ order 15 retneved m res P onse to a fast 

further includes a second table, and wherein calling command, and at least one of the plurality of groups of data 

further includes invoking the second extract function to & * e second order is retrieved in response to a second 

extract a second key from the network packet, and the 15 command. 

second update function to update the second table 18. The data collection system of claim 12 wherein time 

according to the second key. based statistics of the computerized network are periodically 

13. The data collection system of claim 12 wherein stored. 

function calling includes invoking the second extract rune- 19 ^ ^a collection system of claim 12 wherein the 

tionto extractasecondkeyfrommenetwo^ lurali of comol structures h maR gt& as a linked list of 

second update function to update the first table according to stn]CtuICS< ^ wherein a ^ntrol structure is inserted 
the second key. 

14. The data collection system of claim 12 wherein the mt0 me nmcea mL 

first table includes a plurality of rows respectively identified 20 The collection system of claim 12 wherein the 

by a plurality of keys, and wherein invoking the extract 25 plurality of control structures is arranged as an array of 

function includes updating one of the plurality of rows control structures, and wherein a control structure is added 

respectively identified by the first key. to an end of the array. 

15. The data collection system of claim 14, wherein 

function calling includes invoking a create function when ***** 
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[57] ABSTRACT 

In a computer database system, a method and system are 
provided for interactively and iteratively constructing a 
query using a table metaphor displayed on a user display. 
Alterations are made directly to the table metaphor by the 
database user. Hie alterations relate to adding, deleting, or 
combining columns of attributes and limiting ranges of 
attribute values. The alterations are registered and the table 
metaphor updated to reflect the registered alterations. The 
table metaphor can be repeatedly used to further register 
additional alterations. The query corresponding to the table 
metaphor in its final form is run against the full database to 
generate a report in the format indicated by the table 
metaphor. 
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COMPUTERIZED REPORT-BASED 
INTERACTIVE DATABASE QUERY 
INTERFACE 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

This application is a continuation of U.S. Pat No. 5,426, 
781, filed on Apr. 30, 1992, entitled "COMPUTERIZED 
REPORT — BASED INTERACTIVE DATABASE QUERY 
INTERFACE" in the name of Craig A. Kaplan, et al. 

TECHNICAL FIELD 

This invention relates to computerized database systems. 
More particularly, this invention relates to an interactive 
interface for graphically formulating a relational database 
query and simultaneously formulating a report format to 
display the results of the query. 

BACKGROUND OF THE INVENTION 

Computer databases that store data electronically are 
commonly used for retrieving data more efficiently and 
easily than paper file storage methods. Database systems can 
be used to produce reports organizing the data for output to 
the user in clear formats. For example, an employee data- 
base can contain data on employees such as their respective 
names, salaries, departments, managers, and employee IDs. 
This information can be periodically retrieved and organized 
into reports, such as a report on all employees having 
salaries in a given salary range. The report could specify, for 
those employees having a salary in a given range, their 
names, employee IDs and departments. Similarly, a report 
can be produced on every employee in a given department, 
containing their names and employee ID. 

One type of computer software database management 
system for logically organizing the data stored in the data- 
base is a relational database management system (RDBMS). 
In a RDBMS, the data is logically stored in tables having 
columns corresponding to attributes of the data (such as 
employee ID. salary, and department number) and rows 
corresponding to the records of grouped attributes (such as 
the attributes for a given employee). Query languages such 
as the structured query language (SQL) are used to query the 
database and extract particular portions of the data, such as 
a list of particular attributes of employees having a certain 
range of salary, as described above. 

In order to generate the report, a database user has to be 
fa miliar with the commands and syntax of the query lan- 
guage used by a given database. This can require special 
training and expertise to write queries to generate reports. 
Hie user, interested in creating a report, is side-tracked first 
into learning this special language to find the data for the 
report For example, there is a need to know the logic used 
by the query language, which can be counter-intuitive. If a 
user were to try to determine all employees who live in 
Oklahoma and Kentucky, the user would intuitively want to 
generate a query command asking for users in "Oklahoma 
and Kentucky." However, there is a difference between the 
'and' as used in common English language and the logical 
AND operator used in query languages. In order to deter- 
mine all employees who live in two different states, a logical 
OR has to be used to identify those employees that are 
residents of the first state or the second state. The AND 
operator would be used when trying to identify employees 
that are residents of both Oklahoma and Kentucky. 

When working on a report layout and desired content, the 
database user often needs to make modifications to the 
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report after reviewing the generated report However, in 
most query languages, a simple modification to a report 
content or layout can require completely rewriting a new 
query statement. This query statement has to be run against 

5 the entire database to produce the updated report to be 
reviewed This requires a lot of time from the user and from 
the computer system in which the database system is stored 
and the RDBMS is run. It would be better to be able to allow 
the database user to directly manipulate the report and 

10 immediately see the results of the alterations. 

There are a number of query interfaces that simplify the 
query generation process, such as Query-By-Example 
(QBE) as described by M. M. Zloof, * 4 Query-by-Example: a 
data base language", IBM System Journal, Vol 16, No. 4, 

13 1977, pp. 324 ff. There are query building interfaces which 
simplify query writing by taking advantage of workstation 
based graphical user interfaces. While the current graphical 
interfaces make it easier to formulate queries, there is still a 
need for making the process even easier. Also, there is a need 

20 to improve the process of generating reports by allowing a 
user to formulate a query and design the report format at the 
same time. Particularly since people who work in a business 
environment are familiar with reports and since the goal in 
querying a database is to produce a report, it would be 

25 desirable to provide a graphical query interface which 
allows far direct manipulation of a report and for immediate 
feedback of how the database report format would appear. 

SUMMARY OF THE INVENTION 

30 

A method is provided for interactively formulating a 
query and a report format simultaneously using data con- 
tained in the database stored in a computer system having a 
processor, memory, data storage and a display terminal. A 

35 table metaphor is displayed on the display terminal where 
the table metaphor corresponds to a subset of the database 
data. Alterations to the table metaphor made directly by a 
user are registered by the computer. An updated version of 
the table metaphor reflecting the direct alterations is dis- 
played on the display terminal. Further alterations are reg- 

40 istered and updated table metaphors are displayed a plurality 
of times until a final table metaphor is produced. A final 
query is produced reflecting the final table metaphor. The 
final query is run against the entire database to produce 
query output that is formatted according to the table meta- 
phor. 

One of the alterations can be a change to the report format, 
such as movement of the columns of the report One way of 
indicating the movement of the columns is for the user to 

50 graphically move the columns using a mouse or other 
interactive device to click the mouse button after the mouse 
has been used to position the display screen cursor on a 
column, have the column become highlighted, then drag the 
highlighted column to a new location and then unclick the 

55 depressed mouse button. 

Another registered alteration can be the generation of a 
new column based on other columns of the table. One way 
to generate a new column is to allow a user to place an 
operator between two adjacent columns. The new column 

eo generated contains respective attributes of the adjacent col- 
umns combined by the operator. 

Other alterations of the table metaphor are placement of 
range limitations on attribute values for the report output and 
the combination of these attribute range limitations using 

65 AND and OR operations. One method of placing range 
limitations is to allow a user to indicate a cell of the table 
metaphor, display a select row, and then input a range 
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limitation value and operator in the select row in the cell results of the alterations, until the user is satisfied with the 

parallel to the selected cell. Entering more than one value results of table format and content 34. The system then 

and operator on the same select line has the effect of an AND generates a query statement corresponding to the final table 

operation requiring the query response have attribute values metaphor 36, TTiis query can be run against the entire 

within both respective ranges. If the user selects another cell 5 database to generate a final output in the desired report 

in the table metaphor, another select row is displayed. A format 38. 

plurality of select rows have the effect of an OR operation, The foregoing procedure allows a user to generate queries 

where records (table metaphor rows) that satisfy the query without requiring knowledge of query languages. The que- 

satisfy all the respective range conditions of any select row. ries 0311 constructed and refined iteratively before execut- 

The table metaphor rows satisfying the query are highlighted 10 m S ^ ^ uerv 011 ^ entire database. The iterative construc- 

for the user to identify which rows are part of the final tion "? in f j^ 10 . te J 08 * 011 a 

outoU k centralized database system. Additionally, reports are for- 

matted at the same time that the queries are constructed, thus 

BRIEF DESCRIPTION OF THE DRAWINGS eliminating a step in the normal process of producing 

FIG. 1 is a flowchart of the preferred embodiment of the 15 ^P 01 ^- 

invention; There are various alteration that a user can input to 

FIG. 2 is an example of a table metaphor, and indicate the format and contents of the final report. One of 

FIGS. 3-8 illustrate alterations of the table metaphor of * c derations that can be hput can relate to changing the 

pjQ 2 placement or the columns of the report, deleting columns, or 

creating new columns by performing an operation on 

DETAILED DESCRIPTION OF THE 20 attribute values of existing columns. Other alterations of the 

INVENTION table metaphor that can be input can relate to placing range 

Referring to FIG. 1, the preferred embodiment of the limitations on attribute values for the report output and to 

invention provides for displaying a table metaphor on a combine these attribute range limitations using AND and 

display screen 10, such as table 14 on display screen 12 ^ OR operations. 

shown in FIG. 2 of sample data from a database. The The alterations are conveyed to the system using interac- 

database is stored in a computer system having memory, a tive graphic devices such as a computer mouse or keyboard, 

processor, a display screen, external storage such as a disk The user controls the placement of the cursor 15 and signals 

drive, and interaction means, such as a mouse and keyboard, the system. The location of the cursor in relation to the table 

for enabling a user to interact with the system. The interac- 30 metaphor when the system is signalled indicates to the 

tion means can comprise positioning means for a user to system the further prompts to be provided in order to register 

position a cursor 15 on the display screen and execution further input from the user. The user also interacts with the 

means for the user to signal the system. An example of system using menu 40 sequences prompting input 

positioning means and, execution means is a mouse, having FIGS. 3-8 illustrate same examples of the direct alter- 

means for allowing a user to interactively control the posi- 35 ations to the table metaphor 14. Referring to FIGS. 3 and 4, 

tion of the display screen cursor 15, and an associated button one alteration of the table metaphor can pertain to rearrang- 

which can be depressed to signal the system. There are other ing columns in the final report Far example, the user may 

such devices known to those skilled in the art for interacting want to move the salary column 22 closer to the commission 

with a computer system which can be used with this inven- column 20 so that it is easier to read the final report In most 

tion. 4Q database systems, the query language would provide a 

Tlie daUba^c from which the table metaphor 14 shown in formatting statement to indicate how the report should 

FIG. 2 is a subset contains information on employees. The appear. However, it is more productive to allow the user to 

table metaphor 14 has columns 16 containing attribute see the results of rearranging columns, while still formatting 

values for the employee name (Name) 18, the employee ID and constructing the report 

(Id) 19, the commission earned by the employee (Com) 20, 45 In a preferred embodiment of the invention, an interactive 

the department (Dept) 21 of the. employee, and the salary device, such as a mouse, is used to move the cursor 15 over 

(Salary) 22 of me employee. The table metaphor 14 contains to the salary column 22. The user signals the system by 

sample data rows 25-29 corresponding to five of the clicking at mat location (depressing the mouse button). The 

employees from the full database. The sample data used in salary column 22 then becomes highlighted as shown in 

the table metaphor is reflective of the range of attribute 50 FIG. 3. While the user is depressing the mouse button, the 

values in the database. Hie table metaphor can be a table of salary column is dragged to a new location. When the salary 

the database or preprocessing can be performed to provide column is at the desired location, the mouse button is 

a table mat is some combination of database tables. released and the salary column 22 is positioned in its new 

The table metaphor 14 is used as a worksheet to determine location as shown in FIG. 4. There are numerous other ways 

the final format of the report, such as which attributes would 55 of moving the columns as are well-known to those skilled in 

be included and the range of the attributes corresponding to the art A column can also be removed by indicating that a 

the data to be retrieved. Referring again to FIG. 1, input from column is to be deleted using any one of a number of 

the user is registered by the system 30. The input indicates methods known to those skilled in the art 

to the system the user's desired alterations to the table Another alteration that can be input by the user pertains to 

metaphor 14. The system processes the input and generates go adding a new column based on existing columns. Referring 

an updated table metaphor reflecting the alterations made by to FIG. 5, a new column 42 of salary plus commission has 

the user 32. The system can also generate the query state- been added next to the commission column 20. The attribute 

ments used to generate the output as indicated by the user's values in the new column 42 are the respective salary and 

alteration. These can be displayed to the user as a tutorial or commission attribute values of the respective employees in 

as further explanation for the alterations entered by the user. 55 rows 25-29. 

The user can continue to alter and update the table A preferred method of generating the new column 40 is to 

metaphor and have displayed on the display screen 12 the allow the user to place an operator such as a phis sign ("+") 
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44 between the salary and commission columns, as shown in 
FIG. 4. The system responds to the operator input in the 
location between two columns and generates the new col- 
umn 42 of the salary column added to the commission 
column. The results are displayed to the user in the updated 5 
tabic of FIG. 5 having the new column 42, The user can 
immediately see the results of the operation for the sample 
data and know how the final output report will appear having 
the new column 42. 

Further alterations which can be input by the user pertain 10 
to providing a range limitation on attributes, so as to identify 
those records having attributes in the specified range value* 
Referring to FIG. 6, a range limitation for the salary attribute 
22 of being less than $20,000 <["20<") 50 has been input by 
the user (the table metaphor in FIGS. 3-8 has salary and 15 
commission values denoting thousands of dollars; so, far 
example, 4i 20" denotes $20,000). Rows 27, 28 and 29 have 
been highlighted since these rows have salary attributes 
51-53 within the specified range 50. In most database 
systems, a user wanting to query the database to find out for 20 
employees having a salary less than $20,000, the employees' 
names, IDs, salary amount, compensation commissions, 
total salary and commissions compensation, and 
department, have to write a query, statement in the syntax of 
the database management system. Then, the output from the 25 
query has to be formatted for the report, also using the 
proper syntax of the query language. The user may run the 
query and view the report only to determine that there are no 
employees satisfying the specified condition. In this system, 
the user can identify what type of range values to specify 30 
based on the sample data attribute values. Therefore, this 
system makes it easier to compose reports with the relevant 
data which otherwise would have to be specified by using a 
query language. 

In a preferred embodiment of the invention, in order to 
find all the employees whose salaries arc less than $20,000, 
for example, the user first selects an individual salary by 
clicking on the cell containing that salary value using a 
mouse or other interactive device. Next, the user types an 
operator such as a "<" sign in the selected column. A select 40 
row 56 is added to the table metaphor to indicate the logical 
condition 50 the user has specified. The system using 
methods well-known to those skilled in the art determines 
which of the sample rows 25-29 have salary attribute values 
22 meeting the specified condition 50, Each of the rows 45 
which fits into the sample data range as indicated in the 
select row 56 are rughlighted (51-53 in FIG. 6). 

Further conditions can be included as criteria for selecting 
rows that will be output in the final report, that is conditions 5Q 
for the query. Referring to FIG. 7, the logical OR operator 
can be used in a condition input by the user. The addition of 
an OR operation can result from the user viewing the results 
of a previous condition. For example, after viewing the 
updated table metaphor in FIG. 6, the user may wish to also 55 
include information on employees who have less than $40, 
000 in commissions, in addition to the employees that have 
less than $20,000 in salary. 

The new condition can be added by the user by position- 
ing the cursor in a cell of the commission column 20 of the 50 
table metaphor and signalling the system. Hie system then 
adds a new select row 60. The user then adds the condition 
of "<40" 62 in the commission attribute cell of the new 
select row 60. 

The rows 26, 27, 28, and 29 that have respective attributes 65 
that fall within the range of the conditions specified in either 
of the select rows 56,60 are highlighted as shown in FIG. 6. 
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The highlighted rows correspond to employees that either 
have salaries less than $20,000 or commission compensa- 
tions less than $40,000, In this way, a user is able to form a 
query involving an OR operation without having to know 
the syntax or logic of a formal query language. 

The user also formulates queries involving an AND 
operation (adding a further condition to be satisfied), using 
the the select rows 56, 60. The user can move the cursor 15 
to a select line and type in the condition in the cell corre- 
sponding to the attribute to have the additional condition. 

Referring to FIG. 8, the user inputs alterations to the table 
metaphor corresponding to identifying employees (and 
attributes regarding the employees) that have a salary of less 
than $20,000 and have total compensation (salary+ 
commission) of less than $50,000 and also identifying 
employees having commission compensation less than $40, 
000 and total compensation less than $50,000. 

The foregoing is accomplished by the user typing the 
value of 50 and the 'less than* operator (*<*) into the 
salary+commission cells 68 of the select rows 56,60. The 
select rows 56,60 shown in FIG. 8 are logically equivalent 
to ((commission less than 40) and (salary plus commission 
less than 50)) or ((salary less than 20) and (salary plus 
commission) less than 50). 

Using this system, the user can decide based on the 
highlighted sample data in FIG. 7 that the desired report 
should also contain output on individuals whose salary is 
less than $20,000 or whose commission is less than $40,000, 
provided that the total compensation is less than $50,000. If 
a query language statement had to be generated, the user 
would have to figure out how to generate the appropriate 
query using ANDs and ORs. 

As illustrated in the foregoing examples, complex queries 
can be interactively formulated using the table metaphor to 
incrementally add more query conditions. More complex 
queries can be built using this method as would be known to 
those skilled in the art 

There are many improvements of using the invention. The 
query requires fewer terms than a query in SQL. The context 
of the interface supplies much of the information that users 
have to type in using other query methods. For example, by 
clicking directly on a column, the user is specifying that the 
next condition entered will apply to that column. It is also 
easier for users to understand what the query will do. For 
example, having the sample data highlighted which matches 
the query allows users to check and refine the query before 
sending it off to the database. The users thus have a more 
accurate understanding of the query before it is issued. The 
user also interacts naturally with the database using the 
metaphor tables. There is also no need to remember com- 
mands or syntax far moving ar combining columns. The 
sample data also helps the user to refine the data more 
accurately and to include or exclude conditions from the 
query that might not otherwise be as easily incorporated. 

While the invention has been particularly shown and 
described with reference to a preferred emrxxiiment thereof, 
it will be understood by those skilled in the art that various 
other changes in the form and details may be made therein 
without departing from the spirit and scope of the invention. 
Accordingly, the method and system herein disclosed are to 
be considered merely as illustrative and the invention is to 
be limited only as specified in the claims. 

We claim: 

1. A computer program on a computer usable medium 
having computer readable program code means embodied in 
said medium for generating a report by enabling a user to 
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interact with a computer system connected to a storage 
device having a database of data, comprising: 

computer readable program code means for causing a 
displaying, on a display screen of the computer system, 
of a table metaphor having rows and columns of 5 
attribute value cells, the attribute value cells containing 
attribute values reflective of a subset of attribute values 
of the database data; 

computer readable program code means for causing a 
registering of direct alterations to the table metaphor; 10 

computer readable program code means for causing a 
displaying, on the display screen, of a revised table 
metaphor graphically representing a revised report for- 
mat reflecting the registered direct alterations; 15 

computer readable program code means for causing a 
query statement, corresponding to the revised table 
metaphor, to be determined; and 

computer readable program code means for causing a 
running of the query statement on the database to 20 
produce query output in the revised report format. 
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2. A computer program on a computer usable medium 
having computer readable program code means embodied in 
said medium far formulating a report using data contained in 
a database stored in a storage device, comprising: 
computer readable program code means for causing a 
providing of a subset of the database data in a displayed 
metaphor table on a display device of a computer 
system connected to said storage device; 
computer readable program code means for causing a 
registering of at least one direct alteration to the meta- 
phor table to graphically represent a report format; 
computer readable program code means for causing a 
query, corresponding to the report format, to be deter- 
mined; and 

computer readable program code means for causing a 
running of the query on the database data to produce the 
report in the report format 

***** 
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SYSTEM AND METHOD FOR SEGMENTING 
A DATABASE BASED UPON DATA 
ATTRIBUTES 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

This patent application is a continuation-in-part of U.S. 
patent application Ser. No. 08/542,266, filed Oct. 12, 1995, 
and entitled "System and Method For Generating Reports 
From a Computer Database", now abandoned. This patent 
application is also related to co -pending U.S. patent appli- 
cation Ser, No. 08/742,006, filed Oct. 31, 1996, and entitled 
"System And Method For Performing Intelligent Analysis 
Of A Computer Database", now U.S. Pat. No. 5,832,496, 
and Ser. No. 08/742,003, filed Oct. 31, 1996, and entitled 
"Hypertext Markup Language (HTML) Extensions For 
Graphical Reporting Over An Internet" now U.S. Pat. No. 
5,748,188. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to expert systems and 
reporting systems, and more specifically to a system and 
method for generating reports from a computer database. 

2. Description of the Prior Art 

Storing large amounts of transaction-level data for later 
analysis (data warehousing) is becoming recognized as an 
enabler for businesses that are seeking a competitive advan- 
tage. Tightening competitive environments and global eco- 
nomic trends are forcing businesses and entire industries to 
search for a means to gain an advantage. This advantage can 
be realized through the use of strategic data relating to their 
business — allowing better and more timely decisions, lead- 
ing to a better understanding of their business and support 
for their customers, that ultimately leads to growth. To make 
use of data warehouses, the data must be retrieved, orga- 
nized and then presented in an understandable format. 

Discovery tools are used to retrieve, analyze and present 
data from data warehouses. These tools can range from very 
complex modeling tools to relatively simple end user query 
tools designed to do no more than mask the complexity of 
the SQL database programming language from the user. 
Automated tools that search the data for trends or relation- 
ships are also considered discovery tools. 

The marketplace is comprised of various tool vendors 
whose products provide solutions for a portion of the entire 
knowledge discovery process. Therefore, to effectively uti- 
lize their data, the user community is forced to pick multiple, 
disjointed tools. In addition, these tools are targeted toward 
the expert user who has an in-deptb knowledge of the data 
and database formats or the various analytic methods that 
are implemented in the tool. Existing products also do not let 
the business user explicitly and iteratively represent business 
knowledge. Finally, the output of existing tools consists of 
tables of numbers that users have to analyze and interpret. 

Data warehouses, and databases in general, typically have 
complex structure organized for efficiency of data retrieval, 
not ease-of-use by the end user. Users, especially business 
users, desire reports in their vocabulary, not the vocabulary 
of the database. While some tools in the marketplace allow 
a user to define new terms and map those terms to the 
database, the management of related sets of new terms is not 
supported. That is, the relationship of a new term to existing 
terms is not automatically detected for the user. 

In addition to these difficulties, it is common for the 
contents of a report to cause a user to desire another, similar 
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report. Saving and re -using sets of related reports (re- 
generating the reports over a new set of data) is also desired. 
The generation of related reports and the re-generation of 
reports over new data is a capability not adequately available 

5 in the marketplace. 

Therefore, it would be desirable to provide a system and 
method for generating reports from a computer database 
which allow a user to retrieve and analyze data with one tool 
without requiring the user to have knowledge of underlying 

to data structures or of the SQL database programming 
language, which allow a user to define new terms and detect 
and manage relationships between terms, which allow a user 
to easily generate related reports, and which allow a user to 
re -run sets of related reports over new data. It would also be 

15 desirable to provide a system and method for allowing the a 
user to segment and partition a database based upon 
attributes associated with the data in the database. 

SUMMARY OF THE INVENTION 

20 In accordance with the teachin gs of the present invention, 
a system and method tor generating jenons fro mycrnnputer 
databa se are provided. A system and method for allowin g a 
ufeer'Ho segmenr'ahd 'paftitio^a database b ased upon 
attribute s ' associated with the data infhe database are als o 

25 provided. 

rf A data base c omputer includes a database containing the 
dafaTlne d ata includ es a Collection or mrormalioll about an 
en ie^FLse nr i h r_ iisy. r J A server computer is coupled to the 
v ^tabasT _ cbmputer and executes a d atabase management 
30 program. A clie nt computer- is cniiplf fl t o the server ind 
- ufll&llt s a metadata managemen t and SQL generator pro- 
gram, ih e application progra m allows a user to define 
predetermined dafa types, to define relationships between 
the data types, to define parameters for the report, to define 
35 a method of analysis.for the report, and to create the report. 
The report summarizes the data in terms of the data types, 
the datajceMQflshjps, and the methodjjfjmalysis. 

BRIEF DESCRIPTION OF THE DRAWINGS 

40 FIG. 1 is a block diagram of the system of the present 
invention; 

FIG. 2 is a block diagram of a client subsystem within the 
system of FIG. 1; 

FIG. 3 is a block diagram of a data abstraction intelligence 
45 subsystem within the system of FIG, 1; 

FIG. 4 is a block diagram of a data and schema manipu- 
lation subsystem within the system of FIG. 1; 

FIG. 5 is a block diagram of a scheduler subsystem within 
the system of FIG. 1; 
50 ^FIGS. 6-12 are views of a tool for creating reports whi ch 
empl oys a graphic user interface; 

FIG. 13 is a flow diagram illustrating how metadata is 
created. 

FIG. 14 is another block diagram of a client subsystem 
within the system of FIG. 1. 

FIG. 15 is yet another block diagram of a client subsystem 
within the system of FIG. 1. 

FIG. 16 is a database heirarchy that may be created 
60 according to the teachings of the present invention. 

FIG. 17 is another heirarchy that may be created accord- 
ing to the teachings of the present invention. 

FIG. 18 is yet another heirarchy that may be created 
according to the teachings of the present invention. 
65 FIG. 19 is a general, high-level data flow between the DAI 
and the other subsystems and components of the system of 
the present invention. 
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FIG. 20 is an architecture of a Serial DAI subsystem of the product "Perry Ellis men's shirt, size 42, color blue", 

FIG. 1. might be represented as "Product: Department: Men's 

FIG. 21 is a flow diagram for the Serial DAI system of Clothing; Manufacturer: Perry Ellis; Size: 42; Color: blue". 

| These values are members of a specific domain for each 

* ' . , . ,t^at 5 at tribute (see below). 

FIG. 22 is another flow diagram for the Serial DAI system «-=-SSSess Indicatois are' classifications across Business 

of FIG. 1. Concepts that are usually related to numerical values (e.g. 

FIG. 23 is a depiction of the addition of a database Sales Volume, Inventory, Price). Business indicators have 

segment in the system of the present invention. methods and formulae that pertain to their computation (e.g. 

FIG. 24 is a depiction of the deletion of a database 10 Total Sales) and causal associations between Business Indi- 

segment in the system of the present invention. cators (e.g. If Price increases Sales Volume should 

™^ ~- ■ , . 4 . f ju„*u- decrease). Within a Business Indicator, segments can be 

FIG. 25 is a description of the processes performed by the , _ . ' . . . , . c ' fl) b . T ,. 

se er of FIG 1 defined which describe a specific group or Business Indica- 

server o . tors of interest (e.g. Senior Customer, Company AProducts). 

FIG. 26 is a diagram showing the relationships and A change Analysis Report is a compound document 

operations with respect to metadata, 15 describing ^Business Indicators over two time periods. 

FIG. 27 is a diagram showing the relationships and Within system 10, one can specify two periods of time and 

operations with respect to the scheduler queue. see the difference of a chosen Business Indicator for that 

FIG. 28 is a diagram showing the relationships and period (e.g., How did this year's sales of textiles compare to 

operations with respect to the return area. last y cars salcs? ) Changp Analysis Reports can report results 

n/- i* • * c i l 20 for a day, week, month, quarter, year, or other defined 

FIG. 29 is a diagram depicting the requests performed by period 

an analyst. A Comparison Analysis InfoFrame is a type of InfoFrame 

DETAILED DESCRIPTION OF THE helps a business user compare the value of two Business 

INVENTION Indicators across the same time period or compare the value 

1. Overview of Basic Invention 25 °* same Business Indicator across two sibling segments 

n r . rrr , - . m.' 1 j c - across the same time period. 

Referring now to FIG. 1, system 10 includes four major q, d Business Indicators are user-defined Business 

subsystems: client subsystem 12, data abstraction intelli- Indicat0 ^ created b combining prim itive Business Indica- 

gence (DAI) subsystem 14, data and schema manipulation tQrs with arithmetic and set operations. 

(DSM) subsystem 16, and scheduler subsystem 18. A Data Warehouse is a very large collection of data that 

In connection with the description of system 10, the 30 ^ housed in one or more databases. These databases usually 

following definitions are provided: res j de on database server computers and can be either in one 

An Alert C ondition is a user-defined co ndi t ion or set of location or distributed geographically, 

"c onditions that when satisfied returns an Alert Messag e. A Dimension defines the high-level categories of entitie s. 

For instance, an Alert Condition may be defined so that For example, in a Retail domain, the dimensions might be: 

when the inventory of brand A shirts drops below 200 35 Product, Market, and Time (Time is a universal dimension 

units for a given week, system 10 produces an Alert applicable to any domain). A dimension has associated with 

Message, InfoFrame or runs another analyst. * set of attributes that can be used to describe its entities; for 

a ai + \a - * ik* f «^;<;«. iu„ *t,,* example, Brand, Manufacturer and Size describe the dimen- 

An Alert Message is a message that notifies the user that s ions of a roduct 

an Alert Condition has been satisfied. From an Alert ^ Sl0 ^ e ° * has an implicit or explicit domain of 

Message the user can select the corresponding InfoF- yalues F()r exa . ^ domam of yahies for the Depart . 

rame to be run. An example of an Alert Message would ment attribute is an ending 0 f the legitimate departments 

be "Alert: the inventory of brand A shirts is below 200." for ^ cnterprise , and me domain of values for the Size 

An Alert InfoFrame is a type of InfoFrame that describes attribute is a non-zero number representing the size in 

an Alert Message in detail. The Alert InfoFrame has a 45 specified units. 

description of what happened, when, and probable A Drill Down Heuristic specifies some relation between 

reasons why it occurred. the measure values of the segments of a free attribute of a 

An Analyst specifies an event in the data which must segment which must be reported to the user. 

trigger an Alert; or specifies the type of analysis and the End Users *"> uscrs for whlch s y stcm 10 15 specifically 

business measures and segments to be reported on in an 50 desi S ned * End users typically have knowledge of a business' 

InfoFrame, and optionally the schedule on which this ^ eratl / ?J) s f d fo ' ^*™V lt " Microsoft 

InfoFrame is to be generated or the event in the data d ™ s ^dows J- V Windows NT & Windows 95 tic). 

... , , . f L T f c End users typically do not have expertise in SQL code 

which must trigger the InfoFrame. Jr .. J .<> , . . J € ,« A t . 

&& generation or the specific data structures of the databases 

A n attribute is a characteristic or feature of an entity they want to ac cess, 

" represented in the warehouse. For example. Color , ss * Enterprise Information Factory (EIF) is a commercial 

Manufacturer, or Size are all attributes of the produ ct software package that allows typical business users to access 

category of Clothing. their data warehouse data. The data warehouse is essentially 

An attribute restriction is an expression th a t r tesXrjcts the a passive environment that usually requires the use of SQL 

value that att ribute can have. For example, in "Pric e is code and knowledge about the structure of the database to 

less than ^ nJTflfl 11 ! the' u less than $10.UO " is a restriction 60 access data. The EIF differs from the data warehouse by 

o n tfi& rnces at tri bute. Another e xa mple mi gEt be: providing a foundation for providing tools to allow users 

"W oman's Clothing or Men's Clothing" is a restric tion without SQL or database knowledge to get data out of their 

o n the Department Attribute. A single attribute valu e. databases. 

like "Blue" or "Men's Clnthin^, ?s also an attribu te An Exception Analyst is specifically an Analyst which 

restriction. 65 runs regularly to test for a trigger condition, and which 

A specific entity (like a product) in the data warehouse is returns an Alert or a Report when the trigger condition 

represented as a set of attributes and values. For example, occurs. 
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If the domain of an attribute is a finite set (like Depart- 
ment above), it is called a finite domain. The alternative is 
an infinite or continuous domain, like Price. 

A Free Attribute is an attribute of a segment which has not 
been restricted to define that segment. Color, Cost, and 
Weight might all be free attributes of the segment "Expen- 
sive Shirts" 

A Heuristic Rule specifies some condition of data, some 
relation between the segment measure values found by an 
analyst, that should be reported to the user in the completed 
InfoFrame. 

HyperText Markup Language (HTML) is an emerging 
standard format for software documents that allows for the 
inclusion of hyperlinks and graphics (pictures, graphs, 
tables) in text documents. A hyperlink is a "hot" area in the 
document (usually text in a different color than the surround- 
ing text), that when clicked on, shows another document that 
is related or linked to the original HTML document. 

InfoFrame Definitions are System Templates that have 
been customized to include particular Business Concepts, 
Business Indicators, Time Intervals, Analysis Type, and 
segments. InfoFrame Definitions can be immediately "run" 
to produce a "InfoFrame", saved to be run later, saved and 
scheduled to be run later, or triggered by another analyst. 

A Knowledge Worker is typically a person familiar with 
SQL, who knows the structure of the Data Warehouse and 
who has an analytical background. In addition, the Knowl- 
edge Worker may use statistical and data analysis packages 
and data modeling tools. 

Managament Discovery Tool (MDT) refers to the overall 
system of the present invention. 

Meta data is the collection of information about the end 
u ser's particular business, and may be one ot three typ es: 
c ore, public or private. A fter installation th is in formatio n is 
stored in the end user's database and is used to tailor rep orts 
t o the cud User's particular business needs. Metada ta 
in cludes, but is not limited to, Business Concepts, Busin ess 
Indi cators, Segments, Attributes, A ttri bute Value s and Mea- 
suf eTRelationship s! — - " 

Thereof e set of metadata is typically set up at installation 
by professional services personnel and the MDT Adminis- 
trator. Core metadata consists of Dimensions, Attributes, 
Basic Measures, Segments and Year definitions. 

Public metadata is only changeable by the MDT Admin- 
istrator and Knowledge Worker user types and is defined and 
modified after installation. Public metadata includes Public 
Composite Measures, Public Measure Relationships and 
Public Segments. 

Private metadata belongs to each user and is only change- 
able by the end user (Business/executive user) user type. 
Private metadata includes Private Composite Measures, 
Private Measure Relationships and Private Segments. 

If an attribute has a finite domain, the Natural Partition is 
the partition where each segment corresponds to each ele- 
ment of the domain. For example, the natural partition of the 
Department attribute is the set of segments "Men's 
Clothing", "Woman's Clothing", etc. 

Object Linking and Embedding (OLE) is a computer 
format that allows objects (e.g., graphs, tables) in computer 
documents to, when double clicked on, bring up the software 
application that created the object (graph, table, document). 

If the user-defined segments for a given partition do not 
cover the domain, then an "Other" segment will stand for the 
rest of the partition. 

A partition is an implicit or explicit division of the 
dimension by the restriction of a single attribute. For 
example, of one takes the Price attribute, and the "less than 
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$10.00" restriction, this defines a partition of products into 
two sets or segments: those products with Price less than ten 
dollars, and those products with Price greater to or equal to 
ten dollars. Note that the sets or segments of a partition must 
5 cover the original set and not overlap, i.e., "Price <$10.00" 
and "Price <$15.00" do not define a partition. 

Primitive Business Indicators are Business Indicators that 
are direcdy mappable to data in the data warehouse. They 
are set up during installation of the present invention and are 
ao not changeable by the end user. 

R eports or InfoFrames are compound documents th at 
display data irom a database y Vj ffi and graphics {e.g., 
graphs, tables). Reports are the result of running a InfoF- 
rame Definition. InfoFrames may be in the HTML format 
15 an d may be OLE 2.0 compliant. 

A Restricted Attribute is an attribute of a segment which 
has be restricted to defined the segment. Product and Price 
might be the restricted attributes of "Expensive Shirts" 

Segments are user-defined groups that are defined within 
20 a Business Concept having a meaningful attribute or 
attributes in common. For instance, the segment "Senior 
Customers" might be those customers whose age is greater 
than 65 years. 

A segment is one part of a partition. Actually, a segment 

25 is a subset of data defined by restrictions on one or several 
attributes. If a segment is defined by several attributes, it can 
be part of several partitions, one for each restricted attribute 
(as shown shortly. This means that, given a segment in 
isolation, one cannot determine which partition it "should" 

30 belong to, and thus, one cannot determine its natural parents 
in the hierarchy). 

A set of segments forms a segment hierarchy under the 
subset relation, with a root that is the "top-level segment", 
which contains all of the members of the dimension. 

35 S^ uctured Query Language (SQL) is a structured lan- 
guage l or viewing" the conte nts ot a relational database. 
^SU ffimarizauon Intofrrame is a type oi intohrame tha t 
shows a roll-up or summarization of a specified Business 
Indicato r a cross one or more specified segments. By .gejfccl^ 

40 irrg~a particular Business Indicator in this report a InfoFrame 
sho wing the "winners" and "losers" for the specified perio d 
ca n be automatically producecH 

System Administrators (MDT Administrators, or MDTA) 
are those users of system 10 who have an intimate knowl- 

45 edge of the databases and data structures of an organization. 
Often the System Administrator has the title of "database 
administrator" (DBA). 

A Text Generation Rule specifies the text that must be 
inserted into an InfoFrame when the some heuristic rule is 

50 satisfied. 

A Trend Analysis InfoFrame is a type of InfoFrame that, 
when defined, shows the trend for a specific Business 
Indicator or indicators over a specified period of time. This 
analysis can aid in forecasting the future by identifying 

55 patterns in past activities. f~ 
Client subsyste m 12 is a single appli cation program whicrk 
h as a graphical us e r interfac e (GUI) 40 and whicrT aUows a 
user to select anc^peciiy parameters for InfoFrlimes^v iew 
InloFrames, pnnTinioFrames,lmd save InfoFrames. Finally, 

60 *Ee~user , "can dehne UGinpOslie Business Indicators' and 
Segiiieiils, tieale Analysts, de^Be-M e^stfre^lauons hips, or 
mpal^Ttie si u u lmli u f Anaiysj^ T^ 

DAI subsystem l'4 provides intellig ent middleware for 
transl ating graphic al User requestsfsel ecting syste m 

65 temp lates, manip ulating aata views, and g ener a ting jfrmen - 
sional queries fo r ret neyi n g data tibffl dalfwfrenouse zj . It 
ahfo" contains rules for choosing default parameters, for 
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c hoosing l ayout and display formats, and for generating te xt 
from datakl)Ai subsystem iTisresponsible fori nstantia ting 
"user Selected InfoFrames and managing several kinds of 
metadata 25 used in this instantiation. This metadata 25 
represents Business Concepts and Business Indicators that 
provide a customizable "dimensionalization" of the rela- 
tional data in data warehouse 24. DAI subsystem 14 also 
processes updates to this metadata 25 that originate in client 
subsystem 12 and handles several other kinds of user 
updates, primarily by passing them to DSM subsystem 16. 

DSM subsystem 16 reads schema from data warehouse 
24, creates data views, and creates a mapping between the 
two. It also uses that mapping to translate the Dimensional 
Queries received from DAI subsystem 14 into^S&j^qn d 
package a nd return the results. 

[Tier subsystem 18 is responsible for for starting 
Analysts which are to run at a scheduled time or on a 
regulare schedule; or Exception Analysts which must regu- 
larly test for a trigger condition in the database. When the 
requested time interval occurs, the Scheduler starts up, 
requests a list of scheduled InfoFrame Requests from DAI 
subsystem 14. From those lists, scheduler subsystem 18 
determines which should be run during the current time 
interval and sends those requests to DAI subsystem 14 as if 
they were sent by client subsystem 12. 

Thus, system 10 is implemented as a three -tier arc hitec- 
ture. Client computer 30 executes client subsystem 12. 
Client computer 30 preferably executes Windows NT, or 
Windows 95, although other operating systems are also 
envisioned by the present invention. Client subsystem 12 
(FIGS. 6-12) is suitable for use with these operating sys- 
tenRrDis ^l ay 22 ana input aevic e 21 allow a userj olsiew 
GU14iTan? enter choicest! meTacIata 25 used in 
aevice 21 may" 



15 



20 



25 



Windows 95 operating systems. Client subsystem 12 
includes log-in module 50, folder management subsystem 
54, segment builder 55A, measure builder 55 B and measure 
relationship builder 55C, analyst definition subsystem 56, 
InfoFrame viewing subsystem 53 and MDT Administrator 
interface 57. 

Log-in module 50 verifies that only one copy of the client 
subsystem 12 is running on computer 30, checks the local- 
ization of computer 30, connects to computer 32, and 
interacts with the user to log him onto client subsystem 12. 
During logon, log-in module 50 verifies a user's name and 
password and then retrieves any user preferences that may 
have been earlier defined. The only request from a user that 
is handled by log-in module 50 is a request to log onto client 
subsystem 12. 

Log-in module 50 issues the following requests: 



creating 



Analysts. Inpur aevice 21 may De a keyboard, mouse, or 
olhei pointing device. Printer 23 allows a user to print a 
InfoFrame. Storage medium 26 allows a user to store an 
InfoFrame or Alert Message. 

Ser ver computer 32 executes DAI su bsystem 14, DSM 
subs ystem 16, and scheduler Subsystem i8. These th ree 
subsystems combine to satisfy user requests from c lient 
s ubsystem II using information from data warehouse 24. 
Server computer 3 2 is pr eferably a multi-processor com- 
pute rand execuies*the Ij M IX^e tatmg system or Windows 
NT"alth ough other comput er ancToperating system configu- 
rati^nS^are also envisioneoD^the present invention. 

Client an djser ver computers 3 0 and 3 2 are prefer ably 
coupled^asyncnronously for rep ortrequests; all other 
r equests are satisfied synchro n orisTy^Communicati on 
between client and server computers Jl) and 31 is preferably 
thrdUgh"TrmsTn1sTio^^lDntrol protocol/internet protocol 
(TCP/IP), although other transmission protocols are also 
envisioned b y the present invention. 
^— — Database computer 34 includes one or more storage 
media 36 containing data warehouse 24. Database computer 
34 is preferably a massively parallel processor computer and 
executes the UNIX operating system or Windows NT, 
although other computer and operating system configura- 
tions are also envisioned by the present invention. Data 
warehouse 24 is suited to run on any computer which 
supports an Open Database Connect (ODBC) interface to 
data warehouse 24. Communication between server com- 
puter 32 and database computer 34 is preferably via ODBC, 
although other database interfaces are also envisioned by the 
present invention. 

Turning now to FIG. 2, client subsystem 12 is an appli- 
cation program which gives a user control over system 10 
and is suitable for execution on top of the Windows NT, or 
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• single program running 


to Operating System (DOS, NT, Windows 




95, etc.) 


• retrieve localization 


to Operating System (DOS, NT, Windows 




95, etc.) 


• connect to server 


to Client/Server module 


• disconnect from server 


to Client/Server module 


• authenticate user 


to Metadata API 60 


• run main menu 


to Main Menu 51 


• run admin menu 


to MDT Administrator Interface 57 



If the user is the System Administrator, log-in module 50 
displays MDT Administrator interface 57 "Setup" menu 
item. If the user is an end user or knowledge worker, a Main 
menu and toolbar interface 51 are displayed, as are the 
interfaces associated with subsystems 53-55. 

MDT Administrator interface 57 is used by a System 
Administrator to perform system administration tasks, such 
as making user-defined segments available globally and 
creating and editing Business Concepts. Interface 62 is 
preferably only available to System Administrators during 
system installation. 

Folder management subsystem 54 handles all functions 
related to manipulating, storing, and retrieving Folder 
hierarchies, and the InfoFrames and Agents that are stored in 
those Folders. It also handles querying from DAI subsystem 
14 for newly-completed InfoFrames, both when client sub- 
system 12 starts up, and then periodically thereafter. 

Folder management subsystem 54 also handles User 
requests for operations on: 

Folders (new, delete, rename) 

Agents (edit, delete, run now, print) 

InfoFrames (view, delete, annotate, print [in cooperation 
with the InfoFrame View Window]) 

Each folder is represented by one folder object. A folder 
stores a list of child folders, a list of InfoFrames, and a list 
of Agents. Folder objects are created and deleted by folder 
management subsystem 54 in response to user requests. 

Subsystems 55B provides a user with the ability to create 
new measures, update measures, or delete existing mea- 
sures. This information is sent to a Metadata API 60 and 
thereafter to DAI subsystem 14 for updating the user's 
Metadata 25. 

Subsystem 55A provides a user with the ability to create 
new Segments, update segments, or delete existing Seg- 
ments. This information is sent to a Metadata API 60 and 
thereafter to DAI subsystem 14 for updating the user's 
Metadata 25. 

Finally^ Subsystem 55 C provide s a user with an interface 
to^modify me a sure relations an d to constrain mea su re rela - 
tions. Tne user selectsTn^current measure and~whether to 
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evaluate that measure's relations hips when it increases or 
de crease: Then~thenuse r canTBe n select from a list of oth er 
m easu res and define their relationship to the current mea- 
su jg^rriese relationships are in trie lorm or. "decreas es", 
"increases", or "is unrelated to the current meas u re jJ 7 Also, 
every relationship between two measures can be con - 
s tgnned. Jne relationship between measures and the^jgon- 
str aints ji lace d upon tnem are saveo"on computer'iTtor use 
-in ^eratingTni'oFrames. ^ 



Analyst definition subsystem 56 handles all functions 
related to user selection of parameters needed to generate 
specific reports. It also allows the user to define and schedule 
Alerts for scheduled reports. 

The user may invoke an existing Analyst, delete one from 
within the folder management subsystem 54, or create a new 
Analyst. The five types of Analysts are: 

Summarization 

Segment Comparison 

Measure Comparison 

Change Analysis 

Trend Analysis 

The Summarization Analyst requires the following user 
selection requirements: 
Analyst name 

Primary measure, other optional measures 
Primary segment, other segments 
Time period 
Optional schedule 
Optional trigger 
type of year used 

optional trigger event (Alert Message, InfoFrame, Run 

another analyst) 
The Segment Comparison Analyst requires the following 
user selection requirements: 
Analyst name 
Primary measure 

Primary segment, a comparison segment 
Time period 
Optional schedule 
Optional trigger 
type of year used 

optional trigger event (Alert Message, InfoFrame, Run 

another nalyst) 
The Measure Comparison Analyst requires the following 
user selection requirements: 
Analyst name 

Primary measure, Comparison measure 
Primary segment, other optional segments 
base time period, comparison time period 
Optional schedule 
Optional trigger 
type of year used 

optional trigger event (Alert Message, InfoFrame, Run 

another nalyst) 
The Change Analysis Analyst requires the following user 
selection requirements: 
Analyst name 
Primary measure 

Primary segment, Other optional segments 
base time period, comparison time period 
Optional schedule 
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Optional trigger 
type of year used 

optional trigger event (Alert Message, InfoFrame, Run 

another nalyst) 
The Trend Analysis Analyst requires the following user 
selection requirements: 
Analyst name 
Primary measure 

Primary segment, other optional segments. 
Time period, Time interval. 
Optional schedule 
Optional trigger 
type of year used 

optional trigger event (Alert Message, InfoFrame, Run 
another nalyst) 

The user can save or run the analyst definition. The user 
is restricted to choosing one Segment from within each 
Business Concept with the exception of Target Segment, in 
which case he may select only one segment and more than 
one child partition of the selected segment. The user may 
choose to schedule an Analyst or to modify or delete an 
existing schedule. Unscheduled Analysts will be run when 
the user commands. Scheduled Analysts will be submitted to 
the server for execution at a later date or periodic execution. 

The user may specify a trigger condition for the Analyst 
to specify an Exception Analyst. When submitted to the 
server it will be run regularly to test for its trigger condition, 
and will return an Alert or an InfoFrame whenever the 
trigger condition occurs. 

The Analyst definition subsystem 56 makes the following 
requests to the folder management subsystem 54: 
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Save 


Check if the user has selected the 




appropriate parameters for the selected 




analyst. Send a request to the folder 




management subsystem 54 to save an 




existing Analyst Definition 


Save As 


Check if the user has selected the 




appropriate parameters for the selected 




analyst. Send a request to the folder 




management subsystem 54 to save an 




existing Analyst Definition 


Submit 


Check if the user has selected the 




appropriate parameters for the selected 




analyst. Send & request to the folder 




management subsystem 54 to submit a 




report generation 



The Analyst definition subsystem also makes the follow- 
ing requests to Metadata API 60: 



Get all Measures 



5$ Get all Business Concepts 



Get a Business Concept's 

Partitions 

Get Partitions 

Get Segments 



The request will be made to Metadata API 
60 each time there is a need for it at the 
initialization point of a dialog 
The request will be made to Metadata API 
60 subsystem each time there is a need for 
it at the initialization point of a dialog 
The request will be made depending on a 
user's selection of a business concept 
The request will be made depending on a 
user selection of a defined Segment. 
The request will be made depending on a 
user selection of a partition. 



InfoFrame viewing subsystem 53 includes a WYSIWYG 
browser which displays a selected InfoFrame on screen, 
when InfoFrame viewing subsystem 53 gets a notification 
from folder management subsystem 54 to view a InfoFrame. 
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If the user decides to drill down from the current InfoFrame, 
InfoFrame viewing subsystem 53 notifies the folder man- 
agement subsystem 54 to send a new report request. 

When the user double-clicks on an InfoFrame or chooses 
"menu item — View" from the File menu Folders, the folder 5 
management subsystem 54 notifies the InfoFrame viewing 
subsystem to view the InfoFrame. When the user clicks on 
a hypertext to drill down from the current InfoFrame, the 
InfoFrame viewing subsystem 53 passes the drill down 
information to the folder management subsystem 54 to send 10 
a new report request to DAI subsystem 14. 

. InfoFrame viewing subsystem 53 includes a parser which 
parses the InfoFram e, and ex tracts the completed repo rt, 
wh ich is written in Hi ML. In an Hi ML rile, HTML tags 
indicate document elements, stru cture, tormatting, and 15 
hypertext Unking to other documents or resources. Th e 
parser then outputs alf^^e Info nnati o^ for display. In the 
current invention, iEe~hvperunK may instance a new Analyst 
a nd a new InfoFrame 

The InfoFrame viewing subsystem 53 allows a use r to 20 
dis^ay^an d format tex t, tables^ and ^r; 
display 2 2 based on the inlormation gatnerei 
A' nearer, a footer, and annotations Tan be a ft 
InfoFrame. The user can save the viewed InfoFrame. The 
user can also save an InfoFrame as a HTML file in either 25 
UNICODE or ASCII code format. A saved HTML InfoF- 
rame can be attached to an e-mail to mail out. Any HTML 
version 3.0 browser, or equivalent, can read the HTML 
InfoFrame. 

Metadata API 60 handles most of the communications 30 
between client subsystem 12 and DAI subsystem 14. These 
communications involve four basic types of data: metadata 
25, InfoFrames, user profiles, and data warehouse schema. 
For metadata communication, Metadata API 60 provides the 
ability to add, delete and update metadata 25. For 35 
InfoFrames, Metadata API 60 provides the ability to request 
a report, get the status of a report, retrieve a report and cancel 
a report request. For user profiles, Metadata API 60 provides 
the ability to add a user, authenticate a user and delete a user. 
The communication for data warehouse schema is to retrieve 40 
it. 

Metadata API 60 allows a user to define new ways of 
looking at a business. A user cannot modify the public 
segments, the basic measures or the public measures. 
However, the user can create new Business Indicators and 45 
new Segments. In a typical organization of users and system 
administrators, only system administrators can create or 
change basic business measures. Administrators and knowl- 
edge workers can create, edit or delete public composite 
measures, public segments and public measure relation- 50 
ships. 

The MetaData API 60 will handle the following requests 
from other client subsystems: 



update metadata 
get report status 
generate repoit 
retrieve report 
retrieve schema 
update schedule 
cancel a report 
authenticate user 
add a user 
delete a user 
update user password 



from subsystems 55A/55B/55C 
from Folder management subsystem 54 
from Folder management subsystem 54 
from Folder management subsystem 54 
from MDT Administrator Interface 57 
from Analyst Definition subsystem 56 
from Analyst Definition subsystem 56 
from Log-in module 50 
from MDT Administrator Interface 57 
from MDT Administrator Interface 57 
from MDT Administrator Interface 57 



55 



65 



Metadata API 60 sends the following requests directly to 
DAI subsystem 14: 



disconnect from computer 32 
send data to DAI subsystem 14 
receive data from DAI subsystem 14 
Turning now to FIG. 3, DAI subsystem 14 includes return 
area manager 70, InfoFrame generator 72, metadata request 
module 74, metadata repository 76, and metadata load and 
update module 78. 

Metadata repository 76 contains a representation of meta- 
data 25 within data warehouse 24. This metadata 25 is the 
core of system 10; it provides a customizable business view 
over the relational data in warehouse 24 and is the primary 
vocabulary for the specification of InfoFrames. Metadata 
repository 76 gets populated at startup time by DSM sub- 
system 16 from the persistent metadata representation in 
data warehouse 24. 

There are four fundamental kinds of metadata 25 in 
metadata repository 76, listed and described below: 

Business Concepts: business concepts represent the busi- 
ness dimensions along which the data can be viewed. 
Each dimension imposes a hierarchy over the underly- 
ing data, and dimensions can be combined to drive 
"drill-down" or "drill -up" operations. For example, a 
simple retail application might have two Business 
Concepts: Market and Product. The Market hierarchy is 
composed of Sales Regions, each of which consists of 
several States, each of which consists of a set of Stores. 
The Product Hierarchy is composed of a set of Depart- 
ments (Home Electronics, Men's Clothing, Hardware), 
each Department is composed of product Categories 
(Shirts, Shoes, Slacks), and each Category is composed 
of individual manufacturer's product lines. Time is a 
dimension that is important in all applications, and will 
be represented in system 10. Users can add new Busi- 
ness Concepts (see below). These, as all of the metadata 
25 in metadata repository 76, must be mapped into 
relational form (that is, into SQL) in order to actually 
query data warehouse 24. Mapping is done by DSM 
subsystem 16 during the process of processing Dimen- 
sional Queries (see below). 
Business Indicators: Business Indicators are the important 
measures of data of interest. For example, product 
Volume, Price, or Current Stock are all Business Indi- 
cators. The use of time in a query further refines the 
idea of a Business Indicator; for example, "Change in 
Volume" applies between two time periods. 
Alerts: Alerts are essentially tests over the data, but they 
are not part of the metadata. They are specified in the 
Analyst in terms of the metadata. For example, a user 
might specify that if the available stock of a product 
falls by some percentage, to generate the appropriate 
InfoFrame. The user also specifies how often to check 
the Trigger condition. A list of Alerts is maintained by 
DAI subsystem 14 and executed by scheduler sub- 
system 18. This metadata 25 is also available to DAI 
subsystem 14 and is used to generate InfoFrame infor- 
mation. 

Measure Relationships: Measure Relationships are simple 
expressions of business causality; for example, 
"Increased Sales mean Increased Profit". This kind of 
metadata 25 is used to generate supporting information 
for a InfoFrame or, alternatively, alert the user to trends 
that run counter to the set of Measure Relationships. 
Metadata 25 is initially created during installation of the 
present invention at the customer's site. The process of 
creating the metadata 25 is illustrated in more detail in FIGS. 
7A-7E. What is included within metadata 25 depends on the 
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industry (some metadata 25 will be industry-specific and 
usable by all companies in that industry), the specific 
customer of the present invention, and the structure of the 
customers data warehouse 24. During installation, some 
industry-specific metadata 25 is used, some company spe- 
cific metadata 25 may be created, and the mapping infor- 
mation needed to map metadata 25 to data warehouse 24 is 
created. All metadata 25, including the mapping 
information, is stored in a set of relational tables. These 
relational tables are kept in data warehouse 24 and used by 
the present invention to create reports for the user. 

Metadata request module 74 handles all requests for 
metadata 25, either from client subsystem 12 or DAI sub- 
system 14. Client subsystem 12 requests metadata 25 from 
DAI subsystem 14 to be presented to the end users. InfoF- 
rame generator 72 requests metadata 25 in order to create 
Dimensional Queries as part of instantiating a InfoFrame for 
a user. A request for metadata 25 might be, for example, a 
request for all sub-concepts of a particular Business Con- 
cept. 

M etadata request module 74 also handles met ad ata 
updates from client subsystem 12. A user adds new Seg- 
ments by specifying a new dimension from which to group 
the data. This dimension must be supported by an existing 25 op: 
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data attribute in the warehouse data. For example, a Product 
may include a List-Price and a Discount- Price. The user can 
s pecify a new di mension called "Disco unt-Factor", specifi ed 
us ing~the percent ditterence between tri e Discount-Price j hd 
the List-Price, an dusej that t o create three new Seg ments: 

Heavily- D is cou n t e d Produ ct s , Sli ghtl v^Di sco u n le.d 

Products, an d Non-Uiscoun tea Products. TJlSs^jgwJSeg- 
jnents Call 116 W be used ln~subse^ejirInj^2EfA^^ 
aTfd, it indicateq Dy the'u&r', 'ma ge~pe~rsistent by wq A&iWi 
badTlnto data Warehouse 24 ~Ey~ metadata Inari^and-^pdate 
module 7cT~ 

Request Structures are passed from one subsystem to 
another when one subsystem requires processing and results 
from another. Request Structures vary according to the type 
of request being sent. Most requests, however, have some 
common attributes, such as an identification field, an owner, 
a name and a description of the request. 

Business Concept Update Requests are sent from client 
subsystem 12 to DAI subsystem 14 and are preferably issued 
only by the System Administrator. Business Concept Update 
Requests are requests for adding a new Business Concept to 
the metadata 25. The requests have the following format: 



BC_ID: ID which uniquely identifies this Business Concept 

BCL.NAME: The name of this Business Concept 

BC_DESC: The description of this Business Concept 

MAPPING: Mapping of this Business Concept to data warehouse tables 



45 



Business Indicator Update Requests are sent from client ss 
subsystem 12 to DAI subsystem 14. Business Indicator 
Update Requests are requests for adding a new Business 
Indicator to the metadata 25. 

Business Indicator Update Requests primarily include 
primitive and C6mpouna requests. Primitive requests na ve eo 
the following format: 



BI_ID: ID which uniquely identifies this Business Indicator 

OWNER: The user who created this Business Indicator 

BLNAME: The name of this Business Indicator 

BL_DESC: The description of this Business Indicator 



14 
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MAPPING: Mapping of this Business Indicator to data warehouse 

tables 

ROLLUP_OP: Operator for performing the roll-up operation 
Compound requests have the following format: 



BI_ID: ID which uniquely identifies this Business Indicator 

BI_NAME: The name of this Business Indicator 
BI_DESC: The description of this Business Indicator 
EXP: The expression which describes this Business Indicator 

function 



Causal Indicator Update Requests are sent from client 
subsystem 12 to DAI subsystem 14. Causal Indicator Update 
Requests add a new Causal Indicator to the metadata 25. The 
request has the following format: 



Cl_JD: ID which uniquely identifies this Casual Indicator 

OWNER: The user who created this Causal Indicator 
CL_NAME: The name of this Causal Indicator 
CLDESC: The description of this Causal Indicator 

BI ID1 : Business Indicator which is the independent variable of this 

causal relationship 

The operator for this causal relationship 
BI_ID2: Business Indicator which is the dependent variable of this 

causal relationship 
RANGE: When OP is +/-, the range where it is + and the range 
where it is - 
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Schema Requests are sent from client subsystem 12 to 
DAI subsystem 14 and may only be issued by the System 
Administrator. Schema Requests are requests to retrieve the 
data base schema from data warehouse 24. This type of 
request is just a simple unformatted message to DAI sub- 
system 14. 

Segment Update Requests are sent from client subsystem 
12 to DAI subsystem 14. Segment Update Requests are 
requests for adding a new Segment to the metadata 25, 
Segment Update Requests have the following format: 



SEG_ID: 


Id which uniquely identifies this Segment 


OWNER: 


The user who created this Segment 


SEG_NAME: 


The name of this Segment 


SEG_DESC: 


The description of this Segment 


SEG_LEVEL: 


Level in the Segment Hierarchy of this Segment 


BC_ID: 


The Business Concept for this Segment 


ATTR_ID: 


The Attribute^) for this Segment 


OP: 


The operators) for this Segment 


VALUE: 


The value(s) for this Segment 



InfoFrame Requests are sent from the Client subsystem to 
the DAI subsystem. This type of request is to create a new 
InfoFrame based on user specified selections. The request 
has the following format: 



SR_ID: 


ID which uniquely identifies this InfoFrame 


OWNER: 


The user who created this InfoFrame 


SR_NAME: 


The name of this InfoFrame 


SR_DESC: 


The description of this InfoFrame 


SR-TYPE 


One of the four types of Info Frames 


BC_ID: 


The Business Concept for this InfoFames 


SEG_ID: 


The Segments) for this InfoFrame 


TIME: . 


The time intervals) for this InfoFrame 



Dimensional Queries are sent from DAI subsystem 14 to 
65 DSM subsystem 16. Dimensional Queries formulate 
requests for data from data warehouse 24. DSM subsystem 
16 converts Dimensional Queries into SQL statements. 
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The DAI subsystem 14 communicates a dimensional 
query to the DSM subsystem 16 as a list of metadata 
segment definitions or partition definitions, a list of metadata 
measure definitions and a Measure Value Table. The DSM 
subsystem 16 converts these to SQL Queries and submits 5 
them to the Data Warehouse 24. The results returned by the 
Data Warehouse to the DSM arc returned to the DAI in the 
Measure Value Table. 

Gient subsystem 12 produces the following outputs to 
DAI subsystem 14: 10 

Business Concept Update Requests 

Business Indicator Update Requests 

Causal Indicator Update Requests 

Schema Requests 25 
Segment Update Requests 
InfoFrame Requests 
Cancel Requests 

DAI subsystem 14 provides the following outputs to 
client subsystem 12: 

Business Concept Structures 
Business Indicator Structures 
Causal Indicator Structures 
Schema Structures 
Segment Structures 
InfoFrames 
Error/Status Codes 

DAI subsystem 14 provides the following outputs to 30 
scheduler subsystem 18: 
Schedule Analyst Request 
Delete Analyst Request 

DAI subsystem 14 provides the following outputs to DSM 
subsystem 16: 

Dimensional Queries 
Metadata Retrieval Requests 
Schema Requests 

D$Msuhsyslrm 16 provides t he following outputs to D AI 
s ubsystem 14 : 
Updated Metadata 
Data from the Data Warehouse 
Database Schema 

DSM subsystem 16 provides the following outputs to data 45 
warehouse 24:* 

SQL Statements 
J)SM ^subsystem 16 r&geiyes the following inputs from 
data warehouse 24: "^^^^S*" 
^Metadata 

Database Schema 

Warehouse Data 

Scheduler 18 provides the following output to DAI sub- 
system 14: 55 
Analyst Definitions 

Metadata load and update module 78 populates metadata 
repository 76 from the persistent metadata stored in data 
warehouse 24 upon system startup. In addition, when a user 
specifies new Business Concepts and indicates that he wants 60 
them saved, metadata load and update module 78 writes 
them back into data warehouse 24 for future use. 

InfoFrame generato r 7?. Ajjfillg tfr. primary purpos e of 
D AI subsystem 14. Report generation begins when a user's 
An alyst conta ining an InfoFrame definit ion is received by 65 
tn e E>Aj. iTieTy pe Of Anal yst is used to select appro priate 
Drill Down Heuristics and Text Generation RulesJrom the 
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s et implemented in the DAI. Drill Dow n Heuristics ace -used 
t o^etermme it there any data relationships betwee n the 
se gments of the free attributes ot the target segm ent^hich 
must be reported, lext rJe' neration Rules are used toLdet er- 
mine What featur es or the target s e gment ought to be 
reporieH anfl~wnat relationship s to sibling segments7"oT her 
segments m the I' tistflCted attributes of the target segm ent, 
oughtjo be reported. I lext feneration rules may specify 
localhuible text, graphs* or tables as appropriate output. The 
output of the Report Generation process is a fully instanti- 
ated InfoFrame returned to client subsystem 12 in the form 
of HyperText Markup Language (HTML), a widely -used 
standard for building portable compound documents. 
InfoFrame generator 72 has several kinds of knowledge: 
Knowledge of how to map Abstract Queries into Dimen- 
sional Queries 
Knowledge of how to use metadata 25 to generate default 
choices (choices not made by the user in the InfoFrame 
Request) 

Knowledge of how to use both metadata 25 and data 
returned from the warehouse to guide the selection of 
both text components 
Knowledge of how to use both metadata 25 and data 
returned from the warehouse to guide the selection of 
different types of graphical presentations. 
For example, the Summary InfoFrame may take as argu- 
ments a Business Concept, a Business Indicator, and a time 
period. The Report Generation Module uses the user 
selected parameters, for example, the Business Concept 
"Product", the Business Concept Segment "Men's Shirts", 
the Business Indicator "Volume", and the time period 
"December 1994" to create a Dimensional Query. This 
Dimensional Query is sent to the Data and Schema Manipu- 
lation subsystem, which translates this query into SQL and 
actually executes it. It returns the computed data to DAI 
subsystem 14, where other Abstract Queries might embed 
the actual number in a bullet. ( *J 

?ther Aljslracj Queries have cond^jonals asso c iat ed with V £ 
them. ' 



50 



iuflcFon the previous example" another partof the 
su fnmary System Template might specif y the creation of a 
graph, showing now the target-b usiness-indicator (volume) 
is apportioned among the segments ot tne target-business- 
concept (shirts). In this case, report generator 72 mak es a 
metadata request to retu rn the set of segmen ts, in this I 
exa mple, the dimension mat specine s the shirt manufa cturer ^) 
Ajfvohime j nformation is requested tor ea ch manuTac turer 
of sh irts. ^Now, additional lniormation guides report gener a- 
t or jilrrthe selectio n a rhpj ce nt grapb.bor examp le, if 
the number of segments (manufacturers in this easel is 
small, like 7 or " less, then a pie graph is approp riate , 
otherwise, a bar graph' is preferred. If the number of seg- 
ments is very large, th en aggregate the bottom 20 peig ejiLpn 
te rms of the business Indicator, in this case, Volumel and 
u se"that aggregate with the label "Other" in the gptph. 

^Return area manager 7U keeps track of InfoFrames and 
Alert Evaluations with positive results by user that are 
waiting for delivery to client subsystem 12. When a user logs 
into system 10, client subsystem 12 issues a request to DAI 
subsystem 14 to return all data for that user in the return 
area. Return area manager 70 retrieves the information from 
the return area on server computer 32 and sends it back to 
client computer 30 through DAI subsystem 14. 

Turning now to FIG. 4, DSM subsystem 16 includes SQL 
generator 80 and metadata query module 82. 

SQL generator 80 transla tes dimensional queries rec e ived 
fro'mfaj SUbsvslem 14 imp auL st ^ men l- 5 " t ^ a *^ c ' ^lc v e 
d ata from data warehouse 24. ^ A Snapping' from business 
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concepts to database entities is stored in the metadata 25 and 
is used in the formatting of the SQL statements. SQL 
generator 80 provides to DAI subsystem 14 for use in 
creating InfoFrames. 

Metadata query generator 82 processes requests for meta- 5 
data 25 submitted by DAI subsystem 14. At system startup, 
DAI subsystem 14 requests all metadata 25 in order to 
initialize the knowledge base. Metadata query generator 82 
i s. also invoked whenever the user modifies his Segments , 
c ausing DAI subsystem 14 to issue an up date metadata 10 
request. 

Turning now to FIG. 5, scheduler subsystem 18 includes 
alert and report scheduler 90. The scheduler periodically 
tests queued Scheduled Analysts and will dispatch those to 
the have come due to the DAI subsystem 14. It will 15 
periodically dispatch all submitted Exception Analysts to the 
DAI subsystem 14 so that they can test for trigger condi- 
tions. The schedule and trigger periods are independently 
configurable by the MDT Administrator. The scheduler 
passes analysts to the CDAI 14B, by way of the Dispatcher 20 
2513 (FIG, 27). 

Turning now to FIGS. 6-12, client subsystem 12 and its 
operation are illustrated in more detail. 

Client subsystem 12 includes a primary overlay 98 which 
appears when client subsystem 12 is executed. Overlay 98 25 
includes three display areas 100-104 within a common 
Folders window, pull-down menus 106, and buttons 
110-120. The Folders window may be maximized (as it is 
shown in FIG. 6) to eliminate its borders, resized, or 
minimized as an icon within client subsystem 12. The 30 
Folders window cannot be closed. 

Display area 100 contains a list of folders, which repre- 
sent the metaphor used by client subsystem 12 in organizing 
InfoFrames and the analysis that creates them. A folder is 
opened by highlighting it and selecting it with input device 35 
21. The first folder in the list is opened by default when 
client subsystem 12 is executed. 

Display area 102 contains a list of InfoFrames within a 
selected folder. A Info Frame may be viewed by highlighting 
it and selecting it with input device 21. An Analysis window 40 
136 appears containing the InfoFrame. The title bar of the 
window indicates the type of preselected analysis that has 
been performed. For example, in FIG. 12, "change" analysis 
was preselected by a user to be the type of analysis to run. 
The Analysis window 136 may be maximized (as it is shown 45 
in FIG. 12) to eliminate its borders, resized, or minimized as 
an icon within client subsystem 12. The Analysis window 
136 may be closed by selecting button 122 (FIG. 12) or by 
a manner well known to users of Windows 3.1, Windows 95, 
and other windows operating environments. 50 

Display area 104 contains a list of Analysts within a 
selected folder. An Analyst is a personification of prese- 
lected operations performed on preselected data for the 
purpose of generating a InfoFrame. An Analyst may be 
viewed by highlighting it and selecting it with input device 55 
21. Analyst Builder windows 130 (FIGS. 7A-7E) appears 
containing the preselected settings saved within the Analyst 
and used to generate the corresponding InfoFrame listed in 
display area 102. (The InfoFrames listed in display area 102 
are arranged in the same order as the Analysts listed in 60 
display area 104, and have the same titles as the correspond- 
ing Analysts). The Analyst Builder window 130 may be not 
be maximized, resized, or minimized as an icon; it may only 
be closed in a manner well known to users of Windows 3.1, 
Windows 95, and other windows operating environments. 65 

Buttons 110-122 (FIG. 6) implement the primary opera- 
tional commands within pull -down menus 106 and are 
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activated using a pointing device. Button 110 calls the 
Analyst Builder windows 130 (FIGS. 7A-7E). 

Button 112 calls a Segments divider within a Business 
Information Setup window 132 (FIG. 8A). Button 116 
deletes a selected file or folder within display areas 100-104. 
Button 118 creates a new folder. Button 120 calls the 
Analysis window 136 with a selected InfoFrame from 
display area 102. Button 122 closes client subsystem 12. 
Button 150 is a print button, button 151 allows the user to 
create measures, and button 152 allows the user to create or 
edit measure relationships. 

With reference to FIGS. 7A-7E, Analyst Builder window 
130 allows a user to define how selected data is analyzed. An 
Analyst is named under the Analyst Name field. A type of 
analysis is chosen under the Type of Analysis field. A 
primary measure to be used in implementing the analysis is 
chosen under the Primary Measure field. Segments to b e 
reported o n are chosen fro m the list of Defined Segments . 
F inally, a'perio d for the Imo Frame is defined under the Time 
S lice Considered tields. A In foFrame ca n be created lmme- 
diatelyby selecting_the Kepofr*Now~button. or ca n_be 
s cheduled as part of a batch of InfoFrames b v,s_electing the 
Sc heduje^Analyst button^ 
~^$ith reference to FIG. 8A, the Segments divider within 
the Business Information Setup window 132 allows Seg- 
ments to be created, modified, or deleted. A description of 
the segment appears in the Description field. Upon activa- 
tion of button 801 by the user, the window 132 of FIG. 8B 
is launched, allowing the user to edit segment definitons. 

With reference to FIG. 9 A, Me asures of information m ay 
be created and modified within the Measures divider ol the 
Business Information Setup window 132. A name for eac h 
Measu re appears in the Measure Name field. A definition of 
a ^Measure appears in the Definition field. Mathematic al 
o perators, Time Slice constraints, Segment constraints, a nd 
c onstraints from other Measures may be inserted into the 
Definition u sing the corresponding buttons below the De fi- 
ni tion held. With respect to FIGS. 9B and 9C. windows "! 32 
m ay be displayed to select measures and select segmen ts, 
respectively. 

~With reference to FIG. 10, Measure relationships may be 
defined and modified within the Measure Relations divider 
of the Business Information Setup window 132. Measure 
relationships are defined in terms of an if-then statement. A 
primary measure and whether it increases or decreases is 
selected in the Measure field, which represents the "If part 
of the If -Then statement. Measures within the Unrelated 
field may be moved to either the Decreases field or the 
Increases field to form the "Then" part of the If-Then 
statement. With respect to FIG. 11, measure relationships 
may be restricted by means of the window 132 of that figure, 

A batch of InfoFrames may be individually scheduled for 
automatic production. Scheduling of InfoFrames is particu- 
larly useful to those users that require periodic InfoFrames. 
InfoFrame time intervals may be selected under the Time 
Interval field, which provides daily, weekly, and monthly 
reporting options. 

With reference to FIG. 12, a sample InfoFrame is shown 
within Analysis window 136. The type of analysis per- 
formed is indicated in the InfoFrame and in the title bar as 
"Change Analysis". The Segment (previously defined within 
the Segments divider of the Business Information Setup 
window 132) is "Store Ages Greater than 3 Years". The 
Measure (previously define within the Measures divider of 
the Business Information Setup window 132) is "Same Store 
Sales". The Time Slice (previously defined in the Time Slice 
Considered fields of the Analyst Builder window 130) is 
"Year to date 1995 vs. Last Year". 
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The InfoFrame provides a concise statement of changes 
that have occurred in the Primary Measure, Same Store 
Sales, and changes that have occurred in Measures related to 
the Same Store Sales, Stores Remodeled, and previously 
defined within the Measure Relations divider of the Business 
Information Setup window 132. The InfoFrame then con- 
tains an explanation, including a graph, for the change in the 
Primary Measure, Same Store Sales. 

InfoFrame may include multiple instances of HTML 
associated with a Measure, representing hyperlinks to text 
data or graphic data representing the results of the Measure. 

Turning now to FIG. 13, a method for creating metadata 
25 using client subsystem 12 is illustrated beginning with 
START 140. 

In step 141, the user specifies a Business Concept. 

In step 1 , 42 r the user specifies one or more attributes fo r 
the Business Concep t. ' "~ ~ • 1 

In step 144, client subsystem 12 provides the user with the 
list of columns of tables in data warehouse 24. 

In step 146, the user maps every attribute to a column. The 
user can provide a textual description of the business con- 
cepts and the attributes. 

In step 148, the user specifies one or more Business 
indicators by "mapping" a Business Indicator to a column in 
a table within data warehouse 24. 

In step 150, client subsystem 12 provides the user with a 
list of columns for the purpose of mapping Business Indi- 
cators as well. 

In step 152, user selects an "aggregate method" for the 
Business Indicator that is mapped, which specifies how 
values for the Business Indicator are aggregated. The system 
supports the following aggregate methods: 

Add 

Average 

Min 

Max 

Count 

Last in period 
First in period 

In step 154, the user selects the unit of measurement, and 
specifies whether the Business Indicator is a currency. The 
user can optionally specify a plural form of the Business 
Indicator, a verb to describe change in the value of the 
Business Indicator, the precision for reporting the Business 
Indicator and a textual description of the Business Indicator. 

In step 156, client subsystem 12 ensures that tables having 
Business Indicator columns can be joined with tables that 
have Business Attribute columns. 

In step 158, client subsystem 12 determines whether the 
user wishes to enter additional Business Concepts. If so, the 
method returns to step 142. If not, the method ends at step 
160. 

The preceding description forms an overview of the 
present invention. The following sections describe the 
invention in further detail, broken into further sections. 
2. Client Subsystem 12 

Ine client subsystem 12 is described in further detail 
below. 

FIG. 14 illustrates a more detailed block diagram of the 
client subsystem 12. Client subsystem 12 contains three 
subsystems: User Interface (UI) 1401, Manager 1402, and 
Server APIs 1403. As its name implies, the user interface 
subsystem 1401 allows the user 1405 to interact with the 
client 12. At this level of detail, it can be seen that the User 
Interface subsystem 1401 uses services of both the Manager 
1402 and the Server APIs 1403; the Manager 1402 also uses 
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services from the Server APIs 1403. The Server APIs 
subsystem 1403 provides high level APIs which abstract all 
client 12 interactions with the DAI subsystem 14. All 
communications between the client 12 and the DAI sub- 

5 system 14 are sent through the Client Server Module (CSM) 
1404, which is described in further detail below. 

FIG. 15 illustrates a block diagram of the client subsystem 
12 having an increased level of detail over the block diagram 
of FIG. 14. The user interface subsystem 1401 contains all 

10 portions of the program that are visible to the user 1405. 
Because this subsystem may be implemented as a standard 
MS-Windows style program, most of the units within the 
interface are either windows or dialog boxes. Each window 
or dialog box in the interface has one main class which 

15 defines its behavior, as detailed below. Some window or 
dialog classes also use other utility classes, which will also 
be defined below, where appropriate. 

The "top level" of control within the client subsystem 12 
is the Application object 1511. Trie application object 1511 

20 is constructed automatically by the Microsoft Foundation 
Class (MFC) library's start-up code. The application object 
has two primary responsibilities: performing login 
validation, and displaying the main frame window. The 
frame window in a Multiple Document Interface (MDI) 

25 application owns the Menus, Toolbar, and Statusbar, and 
creates child window objects. 

The User Login process consists of two steps: getting a 
User Name and Password from the User, and sending them 
to the Connect function of the Server APIs subsystem 1403. 

30 There are four possible results from an attempted Connect to 
the server 32: 
login succeeded 
login failed 

too many login failures 
35 no response from server 32; network down 

Upon an unsuccessful login, the login dialog is 
re -displayed, and the user 1405 may re-enter his/her name 
and/or password. After a certain number of unsuccessful 
attempts (number determined by server 32, not client 12), 
40 the server 32 will return the "too many failures" result, and 
the client 12 program will inform the user 1405 of this result, 
and then exit. If the network or server are down, the client 
12 will start up in "off-line" mode, which allows the user 
1405 to view saved InfoFrames, but not to create or edit 
45 Analysts, or send InfoFrame generation requests. 

Upon a successful connect, the application will display 
the main frame window. A successful Connect result addi- 
tionally returns an indication of whether the user 1405 has 
Administrator (MDTA) privileges; if so, the frame window 
50 is informed, so that special menu items may be enabled. 
The Application object 1511 may make the following 
requests of other subsystems: 



Function Used 


Subsystem 


Connect 


Session Management API [Server APIs 




subsystem 1403] 


Disco anect 


Session Management API [Server APIs 




subsystem 1403] 


Display MaaagerWindow 


Manager Window [UI subsystem 1401] 



The Application object 1511 is an instance of the clnt_ 
App class. It creates one instance each of clnt_ 
UserLoginDlg and clnt__MainFrame. 
65 Class clnt_App is a subclass of the MFC class CWinApp. 
We inherit most of the standard behavior of the CWinApp, 
but override the Initlnstance function, in which we run the 
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User Login process, and if successful, construct our main 
window, an instance of clnt_MainFrame. 

clnt MainFrame is a subclass of MFC class CMDI- 

FrameWnd. We override the On Create function, in order to 
initialize the Toolbar, and Menus, and to create the initial 
Manager Window instance 1512. 

The clnt__MainFrame instance handles some of the Menu 
and Toolbar requests, while others are handled by whichever 
Child Window is active (one of the four Manager Windows 
1512 or the InfoFrame Viewer window 1517, as described 
below). The clnt__MainFrame instance is also responsible 
for enabling/disabling menu items that vary depending on 
which Child Window is active. 

The User Login dialog is controlled by an instance of the 
clnt_UserLoginDlg class, a subclass of the MFC class 
CDialog. The clnt_UserLoginDlg instance displays a dialog 
which asks the User to enter a name and password. The 
name and password strings are returned to the calling 
function when the User clicks the "OK" button. 

Hie Toolbar is controlled by an instance of class clnt_ 
Toolbar, a subclass of MFC's CToolBar. Class clnt„Toolbar 
inherits all functionality from CToolBar, and adds support 
for drag-and-drop. Instances of clnt_Toolbar accept drops 
of one Folder (onto Trash button), one or more Analysts 
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-continued 


Function Used 


Subsystem 


UpdateMeasure 
GctAU Analysts 


Metadata API [Server APIs subsystem 
1403] 

Metadata API [Server APIs subsystem 
1402] 


The Segment dialog uses the following services: 


Function Used 


Subsystem 


AddSegment 
Up date Segment 
DeleteSegment 
GetAllAnalysts 


Metadata API [Server APIs subsystem 
1403] 

Metadata API [Server APIs subsystem 
1403] 

Metadata API [Server APIs subsystem 
1403] 

Metadata API [Server APIs subsystem 
1402] 



The Business Information Setup section 1515 is con- 
trolled by instances of the following classes: clnt_ 
BuildRelationshipDlg, clnt_BuildMeasureDlg, clnt_ 
(onto Trash, RunNow, or View buttons), and one or more 25 BuildSegmentDIg and clnt_BuildRestrictDlg (all 



InfoFrames (onto Trash, View, and Print buttons). 

The Business Information Definition 1515 includes all 
functionality related to addition, modification or deletion of 
Segments, Measures, and Measure Relationships. 

Three dialog boxes are used in the Business Information 30 
Definition 1515 process; one for each type of Business 
Information to be edited. The dialogs are controlled by 
instances of the following classes which are instantiated by 
clnL_MainFrame (in response to User requests through the 
Menu or Toolbar). 
clnt_BuildMeasureDlg 

This dialog allows the user to update or delete an exisiting 
measure, or create a new Measure. 
clnt_BuildSegmentDlg 

This dialog allows the user to update or delete an exisiting 40 
segment, or create a new segment by defining attribute 
restrictions. 

ClntJuildRelationDlg 

This dialog allows the user to update or delete an exisiting 
MeasureRelation, or define a new relationship. 

The Measure Relationship dialog uses the following ser 
vices from other subsystems: 



Function Used 



Subsystem 



GetMeasureRelationship 


Metadata 


API 


[Server 


APIs 


subsystem 




1403J 










AddMeasureRelationship 


Metadata 


API 


[Server 


APIs 


subsystem 




1403] 










DclcteMeasureRelationship 


Metadata 


API 


[Server 


APIs 


subsystem 




1403] 










UpdateMeasureRelationship 


Metadata 


API 


[Server 


APIs 


subsystem 




1403] 











The Measure dialog uses the following services: 



Function Used 



Subsystem 



AddMeasurc 



DelcteMeasure 



Metadata API [Server APIs subsystem 
1403] 

Metadata API [Server APIs subsystem 
1403] 



subclasses of the MFC's CDialog). If the user 1405 selects 
to modify a private segment or measure, the clnt_ 
MeasureDefDlg and clnt_SegmentDefDlg objects will be 
responsible for traversing through the list of existing Ana- 
lysts and InfoFrames and if the segment or measure is found, 
the objects will take the following actions: 
In case of Delete 
A message will be displayed to the User 1405 that deleting 
35 will cause some Analysts to no longer run correcdy. The 
User 1405 will be presented with a list of Analysts that will 
be affected by this deletion. When an Analyst runs on a 
deleted segment or measure an error message will be 
returned. 

In case of Modify 

The newest segment/measure definition will always be 
used. The old definitions will be replaced. 
The User change requests will be transferred to DAI 
45 (through the Server APIs subsystem) for immediate update 
of the Metadata. 

The Analyst Builder dialog box 1513 allows the User 
1405 to select the parameters needed to generate a specific 
5Q InfoFrame (see below). It also allows the User 1405 the 
option of Scheduling and/or defining Trigger conditions for 
an Analyst. To allow this to happen, the main Analyst dialog 
will prompt the User 1405 to complete a sequence of 
sub-dialogs: Measures, Segments, TimeSlice, Schedule, and 
ss Trigger, 

Other portions of the User Interface subsystem 1401 (i.e., 
Menus, Toolbar, or a Manager Window) invoke the Analyst 
Builder dialog 1513 either by passing it an existing Analyst 
object to view/edit, or by passing a NULL parameter, 
60 indicating that a new Analyst is to be created. 

The clnt_AnalystSbeet dialog will instantiate a clnt 

InfoFrameRequest object when the User 1405 requests to 
"Save" on a new Analyst or "Save As" on an existing 
Analyst. 

The clnt_jVnalystSheet dialog makes the following 
requests to other subsystems: 



65 
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Function Used 


Subsystem 


NewAnalyst 


Managej API [Manager subsystem 1402] 


Update Analyst 


Manager API [Manager subsystem 1402] 


Run Anal ystNow 


[nfo Frame Generation API [Server APIs 




subsystem 1403] 


SetFrameDcfinition 


InfoFrameRequest API [Manager subsystem 




1402] 


GctFrameDefi nition 


InfoFrameRequest API [Manager subsystem 




1402] 



10 









-fnnliniipH 


r 1 unction usgo 


ou Do yste m 


SetAdditionalSList 


InfoFrameDeflnition API [Manager subsystem 




1402] 


GetPartitionList 


InfoFrameDcfinition API [Manager subsystem 




1402] 


SetPartiuonLLst 


InfoFrameDefinitioa API [Manager subsystem 




1402] 


GetParentPartition 


InfoFra me Definition API [Manager subsystem 




1402] 


GetParentPartition 


InfoFrameDefinitioD API [Manager subsystem 




1402] 



The clnt__AnalystSheet class instantiates sub -dialogs of 
the following classes: clnt_AnalystMeasurePage, clnt_ 

AnalystSegmentFage, clnt_AnalystTimeSlicePage, clnt_ The clnt_AnalystTimeSlicePage makes the following 
AnalystSchedulePage, clnt _AnalystTriggerPage (all sub- 15 requests to other subsystems: 
classes of MFC's CPropertyPage). These correspond to five 

panels within the main dialog box which the User 1405 will — — ^ _____ 

be led through in sequence. Function used Subsystem 

Also, the Analyst subsystem 1513 will use clnt_MetaTree GetPeriodType 

class and clnt_MeausreMap class which will provide access 20 
to the Metadate tables through MetaData API's. SetPeriodType 



The clnt_AnalystSheet subdialogs will be dynamically GetAnaiysisType 
populated with the proper controls according to the User's 
1405 selection of the Analyst type. The User input from the nc SetAnalysisType 

Dialog interfaces will be saved in a clnt InfoFrameRequest 

object and returned to Manager subsystem to be saved (and 
submitted for scheduling, if a Schedule is present — see 

below regarding further details of the scheduler subsystem 

GetTrendlnterval 

The clnt_AnalystMeasurePage makes the following 
requests to the other subsystems: 



GetYearType 
SetYearType 
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Function Used 


Subsystem 


GetName 


InfoFrameDeflnition API [Manager subsystem 




1402] 


SetName 


InfoFrameDeflnition API [Manager subsystem 




1402] 


GetFrameType 


InfoFrameDeflnition API [Manager subsystem 




1402] 


SetFrameType 


InfoFrameDeflnition API [Manager subsystem 




1402] 


GetTargetMeasure 


InfoFrameDeflnition API [Manager subsystem 




1402] 


SetTargtMeasure 


InfoFrameDeflnition API [Manager subsystem 




1402] 


GetComparisonMeasure 


InfoFrameDeflnition API [Manager subsystem 




1402] 


SetComparisonMeasure 


InfoFrameDeflnition API [Manager subsystem 




1402] 


GetAdditionalMList 


InfoFrameDeflnition API [Manager subsystem 




1402] 


SetAdditionalMlist 


InfoFrameDeflnition API [Manager subsystem 




1402] 


The clnt_AnalystSegmentPage makes the following 


requests to other subsystems: 


Function Used 


Subsystem 


GetTargetSegment 


InfoFrameDeflnition API [Manager subsystem 




1402] 


SetTargetSegment 


InfoFrameDeflnition API [Manager subsystem 




1402] 


GetCompartsonSegmeal 


InfoFrameDeflnition API [Manager subsystem 




1402] 


SetComparisonSegment 


InfoFrameDeflnition API [Manager subsystem 




1402] 


GetAdditionalSList 


InfoFrameDeflnition API [Manager subsystem 




1402] 



SetTrendlnterval 
GetDu ration 
SetDuration 
GetNumDuration 
SetNumDuration 
GetBasePcriod 
SetBasePeriod 
GetBaseThruPeriod 
SetBaseThruPeriod 
45 GetCompPeriod 
SetCompPeriod 
Opera to r- 
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InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTiineSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 

InfoFrameTimeSlice API [Manager subsystem 
1402] 
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The clnt__AnalystSchedulePage makes the following 
requests from other subsystems: 



Funciton 



Subsystem 



60 



GetNumlnterval InfoFrameSchedule API [Manager subsystem 
1402] 

SetNumlnterval InfoFrameSchedule API [Manager subsystem 
1402] 

Getlnterval InfoFrameSchedule API [Manager subsystem 

1402]. 

Setlnterval InfoFrameSchedule API [Manager subsystem 

1402] 

65 GctSUrtDate InfoFrameSchedule API [Manager subsystem 

1402] 
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Funciton 


Subsystem 


SetStartDate 


InfoFrameSchedule API [Manager subsystem 




1402] 


GctNumLimit 


InfoFramcSchedule API [Manager subsystem 




1402] 


SetNumlimit 


InfoFrameSchedule API [Manager subsystem 




1402] 


GctLimit 


I nfoFra meSchedule API [Manager subsystem 




1402] 


Setlimit 


InfoFramcSchedule API [Manager subsystem 




1402) 


GetSchedulcFlag 


InfoFrameSchedule API [Manager subsystem 




1402] 


SetScheduleFlag 


InfoFramcSchedule API [Manager subsystem 




1402] 


GetTriggerFlag 


InfoFramcSchedule API [Manager subsystem 




1402] 


SetTriggerFlag 


Info Fra meSchedule API [Manager subsystem 




1402] 


Operator= 


InfoFra meSchedule API [Manager subsystem 




1402] 


SctSchcdulc 


InfoFrameRcucst API [Manager subsystem 1402] 



The clnt__AnalystTriggerPage makes the following 
requests from other subsystems: 



10 



15 



20 
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Function 



Subsystem 



GctTriggerList InfoFra meTrigger API [Manager subsystem 1402] 

SetTriggerlist InfoFramcTrigger API [Manager subsystem 1402] 

GetMessageFlag InfoFramcTrigger API [Manager subsystem 1402] 

SetMessageFlag InfoFramcTrigger API [Manager subsystem 1402] 

GetFrameFlag InfoFrameTrigger Apr [Manager subsystem 1 402] 

SetFrameFlag Update the state of the frame generation action 

GetAnalystlist InfoFramcTrigger API [Manager subsystem 1402] 

SetAnlystList InfoFrameTrigger API [Manager subsystem 1402] 

Operator- InfoFrameTrigger AP[ [Manager subsystem 1402] 

GetMeasure Trigger API [Manager subsystem 1402] 

SetMeasure Trigger API [Manager subsystem 1402] 

GctOpcrator Trigger API [Manager subsystem 1402] 

SetOperator Trigger API [Manager subsystem 1402] 

GetOperandl Trigger API [Manager subsystem 1402] 

GctOperand2 Trigger API [Manager subsystem 1402] 

SetOperandl Trigger API [Manager subsystem 1402] 

GetOpeiand2 Trigger API [Manager subsystem 1402] 

GetValuel Trigger API [Manager subsystem 1402] 

GetValue2 Trigger API [Manager subsystem 1402] 

SetVMuel Trigger API [Manager subsystem 1402] 

SetValuc2 Trigger API [Manager subsystem 1402] 

Operator- Trigger API [Manager subsystem 1402] 

SetTrigger InfoFrameRequest API [Manager subsystem 1402] 
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The following is a list of userjngut re quirements for 
InfoFrame Type: 

(R=Required, 0= Optional) 
clnt_MeasureDlg 



-J 

each/ so 



Analysis 
Type 



Target 
Measure 



Additional 
Measures 



Comparison 
Measure 



Change 
Segment 
Comparison 
Measure 
Comparison 
Summarization 
Trend 




Analysis 


Target 


Additional 


Comparison 


Type 


Segment 


Measures 


Measure 


Change 


R 


O 




Segment 


R 


O 


R 


Comparison 








Measure 


R 


o 




Comparison 








Summarization 


R 


o 




Trend 


R 


0 




clnt_TimeSliceDlg 


Analysis 


Base 


Comparison 




Type 


Period 


Period 


Time Interval 


Change 


R 


R 




Segment 


R 






Comparison 








Measure 


R 






Comparison 








Summarization 


R 






Trend 


R 




R 



z 



The InfoFrame Viewer Window 1517 displays an InfoF- 
rame on screen (see below). In addition to displaying the 
InfoFrame data, the Viewer 1517 supports the "Drill Down" 
capability by presenting hot spots to the User 1405, and 
generating the appropriate requests when a hot spot is 
selected. The InfoFrame Viewer also gives the User a 
capability to Annotate an InfoFrame. 

When InfoFrame Viewer 1517 is created, it receives the 
name of the InfoFrame file and a pointer to the InfoFrame 
object. This data is parsed (further processing is also done, 
including generating graphs from embedded data), then 
displayed. 

The Parser capability within the InfoFrame Viewer mod- 
ule 1517 is also used for the SaveAs requests; the raw 
InfoFrame data is translated to standard HTML data (i.e., 
MDT-specific graph data is translated into a graphical image 
in a standard format), and is written to a file in either ASCII 
or Unicode characters. The InfoFrame Viewer Window 1517 
also supports the InfoFrame Print function. This function- 
ality is built on the capabilities provided by the CDocument 
and CScrollView classes of MFC. 

The InfoFrame Viewer subsystem 1517 makes the fol- 
lowing requests to other subsystems. 



Function Used 


Subsystem 


Up datelnfo Frame 


Manager API [Manager Subsystem 1402] 


DrillDown 


Manager API [Manager Subsystem 1402] 
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Parser: the clnt_Parser class provides the HTML parsing 
capability for the Client 12 through the following three 
functions: 



Service Provided 



Description 



do Parse 



Called by the InfoFrame Viewer, this function 
parses the given HTML data, and returns a list 
of dnt_Tag objects, each representing 
an element of the HTML Data. The clnt_Tag 
objects can contain lists of sub-Tags, so that 
nesting is preserved. 
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Service Provided Description 

SaveAsHTML_Unicode Called by the Manager 1402 when the 

User 1405 requests to Save an HTML file. 
Parses the HTML data to replace any non- 
standard HTML elements with standard HTML 
data (for example, raw graph data must be 
transformed into a graphic image). Writes 
transformed data into a file, using Unicode 
characters. 

SaveAsHTML_ASC[I Same as above, except characters are written 
out as ASCIL 



Viewer: the Viewer is implemented using the MFC 
Document/View architecture. Class clnt__Viewer is a sub- 
class of CScrollView (MFC), which provides the automatic 
scrolling. Class clnt_ParserDoc is a subclass of C Docu- 
ment. On creation, it instantiates a clnt Jarser object to 
parse the HTML Data. The clnt_Viewer then traverses the 
returned list of clnt_Tag objects and places their visual 
representations in the Window. 

The following collection of controls are used by the user 
interface subsystem 1401: 
clnt_TreeCtrl 

All dialog controls which will be representing segments 
and/or partitions inherit from this class rather than from the 
MFC's CTree Ctrl, clnt _MetaTree control also inherits from 
this class. 
clnt_MetaTree 

This control is used to represent the Metadata segments 
and partitions in a hirerchical format. The following dialogs 
subclass this control: clnt_AnalystSegmentPage, clnt_ 
BuildSegmentDlg, clnt_RestrictMeasureDlg. 
clnt_TopLevelSegmentCombo 

This conttrol is used to represent all Metadata top level 
segments in a DropDown ComboBox. The following dia- 
logs subclass this control: clnt_AnalystSegmentPage, clnt 

BuildSegmentDlg, clnt_RestrictMeasureDlg. 
clnt_DurationCombo 

This control r epresents the user's conditional operat or 
c hoices ip a cimpriown mmhnhnv for mat. The followin g 
dialogs subclass this control: clnt_AnalystPeriodPage, 
clnt_AnalystSchedulePage . 
clnt_ OperatorCombo 

This~control represents the user's conditional opera tor 
choices in a dropdown combooox tormat. The followi ng 
dialogs subcl ass this control: clnt^AnaiystPeriodPag e, 
clnt^Anal ystSchedule Page^ 
ctmlJa teliclit 

T fiSc nnt rnl is used to^represent the locale date. It 
validates the user entry and formats the date properly tor the 
locale. The following dialogs subclass this control: clnt_ 
AnalystPeriodPage , clnt__AnalystSchedulePage. 
Int^ReadOnlyListBox 

This control is used for a non-select listbox. There is no 
dependencies from other subsystems. The following dialog 
subclasses this control: clnt_BuildSegmentDlg 

The clnt_MetaTree control uses the following services 
from other subsystems: 



Function Used 


Subsystem 


GetSegment 


Metadata API [Server APIs subsystem 




1403] 


GetPartition 


Metadata API [Server APIs subsystem 




1403] 



The clnt_TopLevelSegmentCombo uses the following 
services from other subsystems: 



Function Used Subsystem 

GetSegment Metadata API [Server APIs subsystem 

5 1403] 



The clnt_Measure Combo uses the following services 
from other subsystems: 

10 

Function Used Subsystem 

GetBasicMeasure Metadata API [Server APIs subsystem 

1403] 

GctCompositeMcasuic Metadata API [Server APIs subsystem 
15 1403 ] 



The Administrator Interface 1516 consists of two tasks: 
User Account setup, and Metadata Builder. The User 
Accounts setup dialog allows the MDTA (Administrator) to 

20 create and manager User accounts, including login name, 
password, and User type. The Metadata Builder allows the 
MDTA to define Dimensions, Attributes, and Basic 
Measures, to create Segments, map columns for Time 
values, and define Year types. 

25 The User Accounts screen utilizes the clnt__UserLogin 
class from the Server APIs subsystem 1403, The Metadata 
Builder screens utilize nearly all metadata functions pro- 
vided by the Server APIs subsystem 1403. This includes the 
services of classes clnt_Communications, clnt_Dimension, 

30 clnt_Attribute, clnt_BasicMeasure, and clnt_Segment. It 
also uses the clnt_Schema class for access to the Data 
Warehouse schema. 

The User Accounts dialog is controlled by an instance of 
clnt__UserAccountsDlg, a subclass of MFC's CDialog. The 

35 interface that clnt_UserAccountsDlg presents to the rest of 
the system is the standard for CDialog objects; the instance 
is constructed, and then DoModal( ) is called to display the 
dialog. The call to DoModal( ) returns only when the User 
1405 presses the "Cancel" or "Close" button. 

40 The Metadata Builder dialog may be a "wizard" style 
dialog, meaning that it presents a series of sub -dialogs in a 
pre-determined order. The User 1405 may press the "Next" 
and "Back" buttons to traverse the list of sub-dialogs, and 
may press "Cancel" to exit from the Metadata Builder. The 

45 "frame" of the wizard is implemented by class clnt_ 
MasterSetup, which is a subclass of MFCs CPropertySheet. 
The constructor of clnt_MasterSetup creates one instance 
each of the dialog "pages" (clnt_^AttributeDefinition, clnt_ 
AttributeMapping, clnt_AttributeValueDefinition, clnt_ 

50 AutomaticSegments, clnt_BasicMeasureDefinition, clnt_ 
BasicMeasureMap, cmt„DimensionDefmition, clnt_Joins, 
clnt_Time Dimension, cint_YearDefinition). The pages are 
loaded into the "wizard" automatically when it is displayed. 
This is transparent to the rest of the Client application 12, 

55 which simply constructs the Metadata Builder and calls 
DoModal( ) on the instance. 

Each of the "pages" lo ads its initja^lispla y data through 
c alls to the~ Server A Pis 1403 rfleladata classes , and eajc h 
p age responds to the "Save" button by updating its data 

60 through the ServerAPIs 1403. 

~ T he clnt_MasterSetup has one linked list for each type of 
me tadata used. Each list .contains zero or more clnt_ 
je t up Object objects. The cl nt„Se tup Object object contain s 
t wo data members: on e pointer to a CObject and on e 

65 cl nt Objects tate enumeration. clnt_ObjectState can take 

on one of four values: STATE_EXI STING, STATEZNE W, 
STATE DELETED, STATE,_MODIFIED. These linked 
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lists are available to every "wizard" page. Every time tbe 
user 1405 adds, deletes or modifies a metadata object, it is 
added to the appropriate linked list. These linked lists are 
used to determine which o bjects , to , display to the user 1405 
1 [nd which ones to a i^frog_the user 14fe . The United lists 
are also used by the "CANCEL" and "SAVE" buttons. When 
the user 1405 presses the "CANCEL" button, all objects in 
the linked lists are deleted. When the user 1405 presses the 
"SAVE" button, all objects in the linked lists are accessed. 
If the value of the enumeration is STATE_EXI STING the 
object is deleted from the list. If the value is STATE_NEW 
the object is added to the metadata on the server and deleted 
from the list. If the value is STATE__DELETED the object 
is deleted from the metadata on the server and the object is 
deleted from the list. If the value is STXLJvlODIFIED the 
object is updated in the metadata on the server and the object 
is deleted from the list. 

The "SAVE" button on the "wizard" page adds, deletes 
and modifies objects in a certain order. For deleting objects, 
the following table lists the object to be deleted in the left 
column and the associated objects in the right column that 
will be deleted from the linked lists on the Client 12 if they 
exist. The row order in the left column defines which object 
will be deleted, added or modified first. Dimensions would 
be added first and Year Definitions would be added last. 



Object 
Dimension 



Associated objects 
Attribute, Segment 



Attribute 



Enumerated Attribute Value 
Restricted Integer Attribute 
Restricted Float Attribute 
Segment 

Numerical Attribute Restriction 

Enumerate String Attribute 

Restriction 

Partition 

Basic Measure 

Composite Measure 

Constant 
Segment list 
Attribute Measure Join 
Attribute Attribute Join 
Measure Relationship 



Measure Relation Range 
Restriction 

Measure Relation Magnitude 

Measure Relation Segment 

Constraint 

Time Definition 

Time Mapping 

Year Definition 



Enumerate Attribute Value, Restricted 

Integer Attribute, Restricted Float 

Attribute, Segment, Attribute Measure 

Join, Attribute Attribute Join 

<none> 

<none> 

<none> 

Numerical Attribute Restriction 

<none> 

<none> 

<none> 

Attribute Measure Join 

Constant, Segment List, Attribute 

Measure Join 

<none> 

<none> 

<none> 

<none> 

Measure Relation Range Restriction, 
Measure Relation Magnitude 
Restriction, Measure Relation Segment 
Constraint 



<none> 
<none> 

<none> 
<none> 
<none> 



Folder View (includes Folder hierarchy; shows InfoF- 

rames & Analysts in current Folder) 
Pending Queue (flat list of InfoFrames pending in the DAI 

14). 

Note that the Pending Queue window is included with the 
other three Manager Windows because of its similarity in 
construction and interface behavior; the data it displays is 
actually quite distinct from that of the other three Windows. 

Drag-and-Drop features are also supported by the Man- 
ager Windows 1512. The Analyst list, Info Frame list, and 
Folder View can be the source of a "drag" operation (Users 
may drag one Folder, one or more Analysts, or one or more 
InfoFrames). The Folder View may also be the destination of 
a "drag" operation. 

The first three Manager Window types (Analyst fist, 
InfoFrame list, Folder view) use the following services from 
other subsystems: 



20 



Function Used Subsystem 
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30 



35 



45 



When the user deletes an object that already exist in the 
metadata 25 on the server 34, just that object is deleted. The 
"associated objects" for that object will be deleted by the 
DAI subsystem 14. 

The Manager Windows 1512 give the User 1405 access to 
all types of data which are stored by the Manager subsystem 
1402: Folders, Analysts, and InfoFrames, as well as infor- 
mation about Pending InfoFrames. 

There are four types of Manager Windows 1512, each 
offering a different view of this data: 

Analyst list (flat list of all Analysts) 

InfoFrame list (flat list of all InfoFrames) 



GetRootFolder 

GetTrashBui 

GetAll Analysts 

GetAllInfoFrames 

NewFolder 

RemoveFolder 

MoveFolder 

SetFolderName 

MoveAnalyst 

RemoveAnalyst 

MovelnfoFrame 

Removelnf oFra me 

EmptyTrash 

GetChildFolders 

GetlnfoFrames 

GetAnalysts 

RemoveFolder 

RunAnalystNow 

Viewlnfo Frame 

run AnalystBuilder dialog 



ManageT API [Manager subsystem 1402] 
Manager API [Manager subsystem 1402] 
Manager API [Manager subsystem 1402] 
Manager API [Manager subsystem 1402] 
Manager API [Manager subsystem 1402] 
Manager API [Manager subsystem 1402] 
Manager API [Manager subsystem 1402] 
Manager API [Manager subsystem 1402] 
Manager API [Manager subsystem 1402] 
Manager API [Manager subsystem 1402] 
Manager API [Manager subsystem 1402] 
Manager API [Manager subsystem 1402] 
Manager API [Manager subsystem 1402] 
Folder API [Manager subsystem 1402] 
Folder API [Manager subsystem 1402] 
Folder API [Manager subsystem 1402] 
Folder API [Manager subsystem 1402] 
InfoFrameGeneration API [Server API 
subsystem 1403] 
InfoFrame Viewer Window [User 
Interface subsystem 1401] 
Analyst Builder [User Interface subsystem 
1401] 
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The fourth Manager Window, Pending Queue, uses the 
following services from other subsystems: 



Function Used Subsystem 



GetStatus InfoFrame Generation API [Server API subsystem 

1403] 

Cancel Analyst InfoFrame Generation API [Server API subsystem 

1403] 



50 



Each of the four Manager Windows 1512 is controlled by 
a frame object and one or more control objects placed within 
the frame. In all four cases, the frame is represented by just 
one class, clnt_ManagerWnd, a subclass of CMDIChild- 
55 Wnd from MFC. The clnt_ManagerWnd object is param- 
eterized on instantiation to indicate which control object(s) 
it should construct. As the superclass would suggest, it 
behaves as a standard MDI Child Window. 
The control objects within the frame window inherit from 
60 MFC classes which are, in turn, wrappers for standard 
MS-Windows Controls. Classes clnt_AnalystCtrl, clnt__ 
InfoFrameCtrl, and clnt_PendingCtrl each inherit from 
CListCtrl, and display their data in "columned" lists. Class 
clnt_FolderCtrl inherits from CTreeCtrl to display the tree- 
65 like hierarchy of the MDT Folders. These classes are 
instantiated, as needed, by the clnt_ManagerWnd, depend- 
ing on the "style" flag it receives: clnt_AnalystCtrl is used 
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in ANALYSTS mode and FOLDERS mode; clnt_ 
InfoFrameCtrl is used in INFOFRAMES and FOLDERS 
modes; clnt_FoIderCtrl is used in FOLDERS mode and by 
the clnt_SaveAs dialog box (a part of the Analyst Builder); 
clnt_PendingCtrl is used in PENDING mode. 

When the User 1405 begins a drag-and-drop operation, 
the source window of the drag constructs an instance of 
clnt_DragWnd, which then controls the remainder of the 
drag-and-drop. The clnt_DragWnd is given a pointer to the 
object or list of objects being dragged, and also an indication 
of the type of object being dragged. It then sends a message 
to any window the cursor passes over, asking whether it is 
"OK" to drop the object in that window. The windows which 
support drops are clnt_FolderCtrl and clnt_Toolbar (see 
section 3.2.3). When the User 1405 releases the mouse 21 
button, the clnt_Dragwnd sends a message to the destina- 
tion window requesting it to accept the dropped item(s), and 
also sends a message to the source window indicating that 
the drop was completed. 

The Manager subsystem 1402 handles all functions 
related to manipulating, storing, and retrieving Folder 100 
hierarchies, and the InfoFrames and Analysts that are stored 
in those Folders. Because all functions related to storing and 
retrieving this data are encapsulated in the Manager sub- 
system 1402, there will be minimal impact on the other 
Client subsystems if the Folders/InfoFrames/Analysts data 
store moves onto the Server tier 32 in an alternate embodi- 
ment of the present invention. 

As can be seen FIG. 15, the Manager 1402 provides four 
APIs: Manager 1521, Folder 1522, Analyst 1523, and InfoF- 
rame 1524. These APIs correspond to four classes which are 
described in the following sections. The main class in the 
Manager subsystem 1521 is the clnt_Manager class. Three 
data object classes: clnt__Folder, clnt_InfoFrameRequest, 
and clntJnfoFrame, are used by the clnt^Manager, and by 
other subsystems. Access to Manager functions normally 
begins with a call to the clnt__Manager itself, requesting a 
list of Folders, Analysts, or InfoFrames. The objects which 
are returned by these queries can then be displayed to the 
User 1405 for viewing and/or manipulating. Requests for 
changes to any of the data objects pass through the clnt_ 
Manager, which handles storing the changes on disk and, as 
applicable, sending the changes to the Server API subsystem 
1403. 

The Manager subsystem 1402 also provides a "TrashBin" 
capability; that is, when a request to delete an Analyst or an 
InfoFrame is received, the object is placed in the TrashBin, 
and not actually deleted until the next EmptyTrash command 
is received. The TrashBin is persistent between sessions of 
the Client 12. The TrashBin is implemented as an instance 
of the clnt_Folder class. 

There is exactly one instance 1521 of the clnt_Manager 
class in the Client application 12. In order to ensure that only 
one instance will be created, and that it will be safely 
globally available, the class uses the "Singleton" design 
pattern (as described in Gamma, et al., Design Patterns: 
Elements of Reusable Object-Oriented Software, Addison- 
Wesley, 1995, ISBN 0-201-63361-2). In this pattern, the 
class provides a static member function whicb returns a 
pointer to the one instance of itself. The function automati- 
cally creates the instance the first time it is called. The 
constructor of the class is made protected, thus ensuring that 
the class is never instantiated elsewhere. 

Hie clnt_Manager class handles the following requests 
from other subsystems: 
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Service Provided 



Description 
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GetManager 



GetRootFolder 
GetTrashBLn 

GetAI (Analysts 

GetAUInfoFrames 

NewFotder 



RemoveFolder 

MoveFolder 
NewAnalyst 

Up date Analyst 

MoveAnalyst 
RemoveAnalyst 

UpdatelnfoFiame 

MovcInfoFrame 

RcmovelnfoFra me 
DrillDown 

Sa vein fo Frame AsMDTFile 



SavelnfoFrameAsHTML 
File 



45 ImportMDTFile 



EmptyTrash 
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Static class function which returns a pointer 
to the one instance of clnt_Manager. 
See above. 

Returns pointer to top clnt__Folder object. 
Returns pointer to TrashBin (actually a 
clnt_Folder object). 

Returns a list of all Analysts, without regard 
to Folder hierarchy. 

Returns a list of all InfoFrames, without 
regard to Folder hierarchy. 
Creates a new Folder, parameter indicates 
the parent for the new Folder, returns pointer 
to the newly- created clnt_Folder object. 
Removes the given clnt_Folder object; all 
of its sub-folders, Analysts, and InfoFrames 
are also removed. 

Moves the given Folder to a new Parent 
Folder. 

Stores a new clnt_InfoFrame Request 
object in the given Folder, sends to 
ScheduleAnalyst Server API, if a Schedule 
is present. 

Stores changes to an existing 
clnt_InfoFramcRcquest object, sends to 
UpdateAnalyst Server API, if a Schedule is 
present. 

Moves clnt_InfoFrameRequest object to a 
different Folder. 

Deletes the given clnt_InfoFrameRequest 
object; if a Schedule is present, sends a 
Cancel Analyst to the Server API subsystem. 
Stores changes to an existing 
clnt_InfoFrame object (normally 
changes to its HTML data, when 
annotations are added or raw data is 
processed into a graph, for example.) 
Moves the given clnt_JnfoFrame object to 
a different Folder. 

Deletes the given clnt_InfoFrame object 
If requested DrillDown Frame is already 
generated, returns that Frame; if not, sends 
the Frame Generation request to Server API. 
Creates a rile that can be e-mailed, etc. File 
is an "MDT InfoFrame File" — only useable 
by someone who has Client software 12. 
Creates a file that can be e-mailed, etc. File 
is a standard HTML 3.0 file, viewable by 
any HTML Browser program. A parameter 
to the function indicates if ASCII or 
UNICODE output was requested by the 
User. 

Reads in a file previously created by 
SavelnfoFrame AsMDTFile command, stores 
it as an InfoFrame object in a Folder. The 
InfoFrame is then available for viewing 
through standard mechanisms. 
Completely deletes all items currently in the 
TrashBin. 



The clnt_Manager object uses the following services 
from other subsystems: 



Function Used 



Subsystem 



65 



ScheduleAnalyst Analyst API (Server API subsystem 1403] 
UpdateAnalyst Analyst API [Server API subsystem 1403] 
Can eel Analyst Analyst API [Server API subsystem 1403] 

GetStatus InfoFrame Generation API [Server API subsystem 

1403] 

RctrieveFramc InfoFrame Generation API [Server API subsystem 

1403] 



Instances 1522 of class clntjolder are instantiated and 
deleted only by the clnt_Manager object. Other subsystem 
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gain access to clnt_Folder instances starting with the clnt_ 
Manager's GetRootFolder( ) or GetTrashBin( ) functions. 

The clnt_Fo!der object handles the following requests 
from other subsystems: 



Service Provided Description 



GetFolderName Returns name of this Folder. 
SetFolderName Changes the name of this Folder. 
GetChildFolders Returns a list of clnt^Folder objects which arc 

"children" of this Folder. 
Getlnfo Frames Returns a list of clnt_InfoFrame objects which are 

stored in this Folder. 
GetAnalysts Returns a list of clnt_JnfoFrameRequest objects 

which are stored in this Folder. 
RemoveFolder Removes the given clnt_ Folder object; all of its 

sub- folders, Analysts, and InfoFrames are also 

removed. 



Instances 1523 of class clnt_InfoFrameRequest are cre- 
ated by the clnt_Manager object (when restoring saved 
Analysts from disk) and by the clnt_AnalystBuilder dialog 
class (when creating a new Analyst or doing a SaveAs on a 
current Analyst). Other subsystems normally access Analyst 
objects by retrieving them from their Folder (clnt__ 
Folder: :GetAnalysts( )). Instances of clnt_ 
InfoFrameRequest are only deleted by the clnt_Manager 
object. 

The clnt__infoFrameRequest class handles the following 
requests from other subsystems: 



Service Provided Description 

GetName Returns name of this Analyst 

SetName Assigns a new name for this Analyst. 

GetRequestID Return a unique request tD assigned by Manager 

SetRequestID Assigns a unique request ID to the Analyst 
Request 

GetUserName Returns the user name 

SetUserName Assigns a user name to the Analyst Request 

GetFrameDef Returns the clnLJnfoFrameDefinition object for 
this Analyst. 

SetFrameDef Updates the Analyst's FrameDefinition object. 

GetSchedule Returns the clnt__Schedulc object for this Analyst. 

SetSchedule Updates the Analyst's Schedule object. 

GetTriggcr Returns the clnt_Trigger object for this Analyst 

SetTrigger Updates the Analyst's Trigger object 

GetContainingFolder Returns the pointer to the containig foldr object 

SctContaining Folder Updates the pointer to the containing folder object 



The clnt_InfoFrameRequest class does most of its work 
through three helper classes. The clnLJnfoFrameDefinition 
class stores a description of the InfoFrame Generation 
request that will be sent when this Analyst is run (or 
scheduled). 

The cint_infoFrameDefinition class handles the follow- 
ing requests from other subsystems 

Service Provided Description 

GetFolderlD Return the Folder ID assign to the analyst by 

clnt_Folder object 
Assigns the Folder ID to the Analyst. 
Returns the type of analysis Selected for this 
request 

Updates the type of analysis selected for this 
request 

Returns the target measure selected foi this 
analysis. Required 

Returns the comparison Measure selected for 
this analysis. Required only for Measure 



SetFolderfD 
GetAnalysisType 

SetAnalysisType 

GetTargctMcasure 

GctComparisonMeasure 
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Service Provided 



Description 



5 SetComparisonMeasure 



GetAdditionalMList 



10 
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SetAdditionalMList 
GetTargetSegment 
SetTargctSegmcnt 
GetCo mpariso nSegment 

SetComparisonS egment 

GetAdditionalSIist 
20 SetAdditionalSList 

GetPartitionList 

SetPaititionList 
25 GetParentPartition 

SetParentPartition 

30 GetTimeSHce 
SetTimeSlice 



Operator- 



Compariosn Analysis. 

Updates the Compariosn Meausre Selected for 
this analytsis. Required only for Measure 
Comparison Analysis 

Returns a list of Additional measure Objects 
selected for this analysis. Optional. 
Updates the List of Additional measure Objects 
sleeted for this analysis. Optional 
Returns the target segment selected for this 
analysis. Required 

Updates the target Segment selected for this 
analysis. Required. 

Returns the comparison Segment selected for 
this analysis. Required only for Segment 
Compariosn Analysis. 

Updates the Compariosn Segment Selected for 
this analyisis. Required only for Segment 
Comparison Analysis. 

Returns a List of Additional Segment Objects 
selected for this analysis. Optional. 
Updates the List of Additional Segment 
Objects sleeted for this analysis. Optional 
Returns the List of selected target Partitions. 
Optional. 

Updates the List of selected target Partitions. 
Optional. 

Returns the target segment's parent partition. 
Required only if target segment is not top level 
segment 

Updates the target segment's parent partition. 
Required only if target segmetn is not top level 
segment 

Returns the pointer to the timeslice object for 
this analysis Required. 

Updates the pointer to the timeslice object for 
this analyusis. Required. 
Copies the object into another 



35 

The clnt_InfoFrameTimeSlice class handles the follow- 
ing requests from other subsystems: 

40 Service Provided Description 

GetPeriodType Returns the type of timeslice selected for the 
request. 

SetPeriodType Updates the type of timeslice selected for the 

request. 

GetAnalysisType Returns the type of analysis selected for the request 
SetAnalysisType Updates the type of analysis selected for the 
request. 

GetYearType Returns the type of year definition selected for the 

request 

SetYeaiType Updates the type of year definition selected for the 

request 

GetTrcndlnterval Returns the interval duration. Required only for 
Trend Analysis. 

SetTrendlnterval Updates the interval duration. Reuired only for 
Trend Analysis. 
Returns the time duration. 
Updates the time duration. 
Returns the number of durations. 
Updates the number of durations. 
Returns the Specific Date's base period. 
Updates the Specific Date's base period. 
Returns the Specific Date's thru period. 
Updates the Specific Date's thru period. 
Returns the Specific Date's Comparison Period. 
Required only by Change Analysis. 
Updates the Specific Date's Comparison Period 
Required only by Change Analysis. 
Operator- Copies one TImeSlice object inot another. 



45 
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GetDuration 
SetDuration 

55 GetNumDuration 
SetNumDuration 
GetBasePeriod 
SetBasePeriod 
GetBaseThruPcriod 
SetBaseThruPeriod 

60 GetCompPeriod 

SetCompPeriod 
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The clnt_JnfoFrameSchedule class stores definition of a 
schedule for the Analyst. 
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The clnt_JnfoFrameSchedule class handles the following 
requests from other subsystems: 



Service Provided Description 

GctNumlnterval Return Number of intervals the report should run. 
SetNumlnterval Update the number of intervals the report should 
run. 

Getlnterval Return the duration for the interval the report 

should run. 

Sctlnterval Updates the duration for the interval the report 

should run. 

GetStartDate Rutun the date to which the report is scheduled to 

start runing. 

SetStartDate Updates the date to which the report is scheduled to 

start running. 

GetNumLimit Retuns the number of time periods the reports is 

scheduled to run. 

SetNumlimit Updates the number of time periods the report os 

shceduled to run, 

Gctlimit Return the duration for the number of times the 

report is shceduled to run. 
SetLimit Updates the duration for the number of times the 

report is scheduled to run. 
GetScheduleFlag Returns the enabling or disabling state of the 

shcedule. 

SetScheduleFlag Updates the enabling or disabling state of the 
schedule. 

GctTriggerFlag Returns the enabling or disabling state of the trigger 
definition. 

SetTriggerFlag Updates the enabling or disabling state of the 

trigger definition. 
Operator- Copies one Schedule object into another 









-cnntinneH 


Service Provided 


Description 


SetOperand2 


Updates the second operand measure if operator is 




Between or not Between. 


GetValuel 


Returns the first operand value 


GetValue2 


Returns the second operand value 


SetValuel 


Update the first operand value 


SctValue2 


Updates the second operand value, if Operator is 




Between or not Between. 


Operator- 


Copies the object into another 



Each instance 1523 of clnt_InfoFrameRequest must have 
a clnt_infoFrameDefinition object; the clnt__ 
InfoFrameSchedule and clnt_Trigger objects are optional. 

Instances 1524 of class clnt_InfoFrame are instantiated 
by the clnt_Manager object (when restoring saved Analysts 
from disk or receiving a new Frame from the Server API). 
Other subsystems normally access [nfoFrame objects by 
retrieving them from their Folder (clnt_ 
Folder: :GetInfoFrames( )). Instances of clnt_Info Frame are 
only deleted by the clnt_Manager object. 

The clnt_JnfoFrame class handles the following requests 
from other subsystems: 
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The clnt__InfoFrameTrigger class handles definition of 
trigger conditions to be checked before the Analyst is run. 
The clnL-infoFrameTrigger class handles the following 
requests from other subsystems: 



Service Provided 


Description 


GetName 


Returns name of this Info Frame. 


GetHTMLFile 


Returns name of file containing HTML Frame data 




is stored. 


UpdateHTMLFQe 


Informs InfoFrame that it's data file has been 




updated (may be required for annotation, drill- 




down, graph generation). 



Service Provided Description 



GetTriggcrList Return a list of triggers defined by the analyst 

SetTriggerlist Updates a list of triggers defined by the analyst 

GetMessageFlag Return the enable/disable state depending on user 
selection of the action to be taken. In this case a 
message will be generated if trigger becomes true. 
SetMessageFlag Update the state of the message generation action. 
GetFrameFlag Return the enable/disable state depending on user 

selection of the action to be taken. In this case a 
Frame will be genereated if trigger becomes true. 
SetFrameFlag Update the state of the frame generation action 

GetAnalystlist Return a list of analysts to be generated if the 

trigger becomes true. If List empty, this action is 
not selceted. 

SetAnlystList Update the list of analyst to be generated if the 

trigger becomes true. If List empty, this action is 
not selected 

Operator** Copies the object into another 



The Server API subsystem 1403 encapsulates all func- 
35 tions which require communication with the MDT Server 32 
(DAI 14). This isolates the User Interface 1401 and Folder 
Manager 1402 subsystems from specific knowledge about 
the Client-Server interface, keeping them independent of 
minor changes, etc. 
40 As seen in FIG. 15, the Server APIs 1403 can be divided 
into four API modules: Metadata* 1531, InfoFrame Genera- 
tion 1532, Data Warehouse 1533, and Session Management 
1534. The Server APIs subsystem 1403 also includes a set of 
internal routines for talking to the CSM 1404, which are 
45 shared by the four APIs. Each module is described below. 
_ The Metadata API 1531 handl es all Client 12 requests to 
view or modity portions' Of the MPT Metadata 25. Again th e 
Metadata 25 reside s on the server 34, and the Client 1 2 
relfleTes" Pieces ot trie Metadata 25 npwte^ via th* P>AI 
14. 
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The class clnt_trigger contains a single trigger condition. 
A list of clnt_trigger objects will be ANDed and defined as 
a single trigger. The clnt_Trigger class handles the follow- 
ing requests from other subsystems: 



The MetaData API 1531 provides the following services 
to other Client subsystems: 



55 Service Provided 



Description 



Service Provided Description 



GetMeasure Returns the measure selected. 

SetMeasure Updates the measure seleceted 

GetOperator Returns the operator selected 

SetOperator Updates the operator selected 

GctOperandl Returns the first operand measure 

GetOperand2 Returns the second operand measure if operator is 

Between or not Between. 

SetOperandl Updates the first operand measure 



60 



GetDim ens ions 

AddDimension 
Up dateDimens ion 
DeleteDimension 
GetDimensionPartitions 

GetPartitions 



AddPartition 
Update Partition 
65 Delete Partition 
GetSegments 



Returns a list of clnt_Dimension objects 

representing all Dimensions. 

Add a new Dimension. 

Update an existing Dimension. 

Remove an existing Dimension. 

Returns a list of clnt_Partition objects for all 

Child Partitions within a given Dimension. 

Returns a list of clnt_Partition objects for all 

Child Partitions within a given Segment. 

Add a new Partition. 

Update an existing Partition. 

Remove an existing Partition. 

Returns a list of clnt^Segment objects for all 
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-continued 



Service Provided 



Description 



defined Segments within a given Partition. 
Add a new Segment. 
Update an existing Segment 
Remove an existing Segment 
Returns 3 lists: Basic Measures, Composite 
Measures, and all Measures which are 
accessible to the User (some Measures arc 
used internally in the Client code). 
Add a new Measure. 
Modify an existing Measure. 
Remove an existing Measure. 
Retrieve a Measure Relationship. 
Add a new Measure Relationship. 
UpdateMeasureRelationship Update an existing Measure Relationship. 
DeleteMeasureRelationship Remove an existing Measure Relationship. 

Retrieve possible Relationship types for a 
given Attribute. 

Retrieve range of values for a given 
Attribute. 



AddSegment 
UpdatcScgment 
DeleteSegment 
GetMeasures 



AddMeasure 

Update Measure 

DeleteMcasurc 

GetMeasureRelationship 

AddMeasureRelationship 



GetRclationships 
GetRange 
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The Metadata API uses the Communications Services 
module (see below) to communicate with the CSM 1404. 

Several classes work together to provide the set of ser- 
vices listed in the table above. Class clot_Dimension has 
public methods: GetDimensions (a static class method), 
AddDimension, UpdateDimension, DeleteDimension, and 
GetDimensionPartitions, AddDimensionPartition, Delete- 
DimensionPartition. Class clnt ^Partition has public meth- 
ods: GetSegments, AddSegment, DeleteSegment, 
UpdatePartition. Class clnt_Segment has public methods: 
GetPartitions, AddPartition, DeletePartition, UpdateSeg- 
ment. Measure functions are represented by two classes: 
clnL_BasicMeasure and clnt_CompositeMeasure. 

The InfoFrame Generation API 1532 contains all func- 
tions related to requesting that the DAI 14 run or schedule 
an Analyst, and retrieving status and completed InfoFrames 
from the DAI 14. Functions in this API 1532 are used by the 
Manager subsystem 1402 and the User Interface subsystem 
1401. 

The InfoFrame Generation API 1532 provides the follow- 
ing services to other Client subsystems: 



Service Provided 



Description 



Gettnfo FrameGenerationlnstance 



GetStatus 



RetrieveFrame 
RunAnalystNow 

ScheduleAnalyst 

Up date Analyst 
CancelAnalyst 



Returns a pointer to the 
one-and-only-one instance of 
clnLJnfoFrameGeneration. 
Query the DAI for list of currently 
pending and/or completed 
InfoFrames. 

Retrieve a specific completed 
InfoFrame from the DAI. 
Send an InfoFrame Generation 
request to the DAI for 
immediate processing. 
Send an InfoFrame Generation 
request to the DAI with a 
schedule on which to run it 
Send the DAI a modification 
to an existing, scheduled Analyst. 
Cancel a previously scheduled 
InfoFrame Generation request 
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The Data Warehouse API 1533 provides services related 
to setting up Metadata 25, at which time the MDTA 
(Administrator) needs access to information about the 
schema of the Data Warehouse 24. This API 1533 cis 
encapsulated in the clnt_Schema class. The Data Ware- 
house API 1533 provides the following services to other 
MDT Client subsystems: 



10 



Service Provided 



Description 



GetThbles Returns a list of names of Tables from the current 

Schema data. 

GetColumns Returns a list of names of Columns from a given 

Table. 

GetPrimaryKeys Returns a list of names of Primary Keys in a 

15 given Table. 

GetForeignKeys Returns a list of Foreign Keys in a given Table. 

ForeignToPrirnary Returns a list of Primary Keys associated with a 

given Foreign Key in a given Table. 
PrimaryTo Foreign Returns a list of Foreign Keys associated with a 

given Primary Key in a given Table. 
LoadSchema Loads schema from server; returns True if 

successful. 



35 



40 



The Data Warehouse API 1533 also uses the Communi- 
cations Services module to communicate with the CSM 
1404. 

The Data Warehouse API 1533 is encapsulated in the 
clnt_Schema class. The clnt_Schema class has public 
member functions which correspond directly to the API calls 
described in the table above. The LoadSchema function 
loads all of the Data Warehouse schema onto the Client for 
the other API functions to access. The schema is discarded 
after each use. 

The Session Management API 1534 contains functions 
related to establishing a session with the MDT Server (and 
to closing the connection when exiting). This includes 
functions related to User and Password management. The 
Session Management API provides the following services to 
other MDT Client subsystems: 



Service Provided Description 



The InfoFrames API 1532 also uses the Communications 
Services module to communicate with the CSM 1404. 

The InfoFrame Generation API 1532 functions listed 
above are public members of the clnt_Info Frame Generation 
class. The clnt_InfoFrameGeneration class will be instan- 
tiated only once, using the "Singleton" pattern (described 
previously). 



GetScssionManager Returns pointer to the one-and-only-one instance 

of class clnt_SessionManager. 
Connect Establish a connection to the Server and 

attempt to authenticate the given User Name and 
45 Password. 

Disconnect Orderly shutdown of our connection to the Server. 

UpdateUserPassword Change a User's password on the Server. 



The Session Management API 1534 also uses the Com- 
munications Services module to communicate with the CSM 
1404. 

The Session Management functions listed above are pub- 
lic member functions of class clnt__SessionManager. Class 
clnt_SessionManager is instantiated once and only once, 
using the "Singleton" pattern. 

The Communication service encapsulates functions for 
talking to the DAI 14 via the CSM 1404. These functions are 
shared by the four APIs 1531, 1532, 1533 and 1534 within 
the Server APIs subsystem 1403. The Communications 
Services capabilities are encapsulated in class clnt_ 
Communications, which will be a private superclass for all 
other classes in the Server APIs subsystem 1403. 
3. Data Abstraction Intelligence (DAI) Subsystem 14 

The data abstraction intelligence subsystem 14 is 
described in further detail below. 

A key feature of the present invention (also referred to as 
Management Discovery Tool or MDT) is that it allows the 
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user 1405 to easily choose different levels of granularity in 
the viewing and understanding of the business objects of 
interest, and have these different levels reflected in InfoF- 
rames generated by the MDT. For example, when the user 
1405 thinks of the concept of product, he or she may mean 
all products marketed by the Enterprise, or, more likely, 
some interesting subset of all products. This subset can be 
defined by restrictions on the attributes of product, either a 
single restriction such as men's clothing (defined as the 
product Departmentomen's clothing), or multiple 
restrictions, such as expensive men's suits made by Chris- 
tian Dior (similarly defined by restrictions on Department, 
Price, and Manufacturer). 

One of the insights in the design of the present invention 
is the notion that such subsets form hierarchies, and that 
these hierarchies may provide a convenient and powerful 
way for the user to both think about their business and select 
relevant levels or granularities for the production of InfoF- 
rames. An important technical point, but one that is kept 
partially hidden from the user 1405, is how related segments 
form partitions. 

The Management Discovery Tool of the present invention 
sits on top of a data warehouse 24, a single logical, consis- 
tent view of an enterprise's data. Typically, there are many 
different ways to store data; that is, there are different table 
structures or schema for a given set of data. For most, if not 
all, enterprises, there exists a small set of fundamental data 
types that are the lowest level of granularity and correspond 
to, typically, specific entities like product, customer, 
transaction, and the like. These entities can be thought of as 
having a set of attributes associated with them, and these 
attributes can have values. In the relational model, this 
corresponds to a table of entities, with the attributes mapping 
into columns. Again, physically, they may be stored as 
several tables, but conceptually, this is what MDT is work- 
ing with. 

FIG. 16 illustrates the hierarchy formed by the user 1405 
choosing the Department attribute 1601, then selecting 
segment Men's Clothing Department 1602 of the attribute; 
of choosing the Product-type attribute 1603, then selecting 
the segment Shirts 1604 of that attribute; the Manufacturer 
Attribute 1605, then Perry-Ellis 1606; and finally, the Size 
attribute 1607, and a particular partition 1608 k 609. The 
final Business Segment of interest is: "Perry Ellis Men's 
Shirts". Note that this segment could have been reached in 
several different ways, in particular, by any order of relevant 
attributes. 

This scheme creates several requirements for other parts 
of MDT. First, the attributes of each dimension must be 
available. Second, the legitimate values for each attribute 
must also be made available. For finite domains, these must 
be listed for the user 1405; for infinite domains, current 
minimum and maximum values may be useful. There is a 
subtlety here that can perhaps be avoided at first: the 
possible attribute values may not, in fact, be appropriate in 
all cases. In the above example, all Manufacturers may not 
make Men's Shirts. It may be possible to query the database 
for legitimate values, or store this information as additional 
metadata. 

An important requirement of the present invention is to 
provide the ability to save and re-use user-defined segments. 
If "Perry-Ellis Men's Shirts" is an important category to the 
user 1405, he or she should be able to save that category and 
re-use it in the generation of InfoFrames. Our approach 
allows users to define segments and automatically keeps 
these segments in a hierarchy. The table below provides a set 
of named segments and their definition, i.e. the restrictions 



on their attributes. All segments are on the dimension 
"Product". 
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Name 


Dept. 


Maker 


Type 


Size 


Men's Clothing 


MC 








Men's Shirts 


MC 




Shirts 




Perry-Ellis Shirts 




Perry-Ellis 


Shirts 




Perry-Ellis Men's Shirts 


MC 


Perry-Ellis Shirts 




Men's Pants 


MC 




Pants 




Large Men's Shirts 


MC 




Shirts Large 


Large Men's Pants 


MC 




Pants 


Large 


Gap Products 




Gap 






Perry-Ellis Products 




Perry-Ellis 






Guess Products 




Guess 






Medium and Large Men's 


MC 






Medium + large 


Clothing 










Small Men's Clothing 


MC 






Small 


Small Men's Shirts 


MC 


Shirts 




Small 



The segments described above give rise to the segment 

20 hierarchy depicted in FIG. 17. Note that there is an inherent 
ambiguity in this structure: a given Business Segment can 
belong to several different partitions and have children 
beneath it whom are in several different partitions. For 
example, the Segment "perry-ellis-men's-shirts" belongs to 

25 two partitions. The first partition is on "perry-ellis-shirts" 
and uses the value "men's" to further discriminate (note the 
"Other" segment would now mean "perry-eliis-shirts-but- 
not-for-men". This segment is also part of a partition on 
"men's-shirts", and restricts the Manufacturer attribute to be 

30 perry -ellis. Here, the "Other" segment indicates "men's- 
shirts-made-by-everybody-but-perry-ellis". 

In order to resolve the ambiguity, the notion of partition 
must be made explicit. Thus, FIG. 17 may be re -drawn as 
shown in FIG. 18 to include partitions (dark boundaries) and 

35 the "Other" segments. We now see from FIG. 18 that the 
notion of "partition" is just as important as the notion of 
"segment"; indeed, the two notions cannot be separated. 

Referring back to FIG. 1, the MDT Data Abstraction 
Intelligence (DAI) subsystem 14 sits between the Client 

40 subsystem 12 and the Data and Schema Manipulation 
(DSM) subsystem 16. The DAI 14 (and the DSM 16) reside 
on the Applications Server 32 between the Desktop 30 and 
the Data Warehouse 24. The DAI 14 is responsible for 
instantiating user selected InfoFrames and managing several 

45 kinds of metadata used in this instantiation. This metadata 
represents (1) Dimensions and Measures that provide a 
customizable "dimensionalization" of the relational data in 
the warehouse; (2) Measure Relationships that provide 
explanatory text in the InfoFrame; and (3) metadata related 

50 to time. The DAI 14 also processes updates to this metadata 
that originate in the Client layer 12 and handles several other 
kinds of user updates, primarily by passing them through to 
the DSM 16 subsystem. Finally, the DAI 14 executes Alert 
requests from either the Client 12 or the Scheduler sub- 

55 system 18. 

The design of the overall Client/Server envisions two 
kinds of DAI subsystems 14. The first kind of DAI 14 is 
needed to handle continual, synchronous requests for infor- 
mation from the Client 12. For example, the Client 12 may 

60 make a number of requests for metadata information during 
an active MDT session; the S-DAI (for Serial DAI) will 
handle these requests. 

The second kind of DAI 14 will execute an Analyst, 
which may contain a trigger definition or an InfoFrame 

65 definition. This execution may take a relatively long time 
(e.g., hours) and will execute concurrently. This type of DAI 
14 may be called the C-DAI, for Concurrent DAI. The 
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C-DAI is spawned by an S-DAI in response to an Info Frame 
request and given all the information it needs. When it is 
finished, it will write the resulting Info Frame into a server 
disk file. 

FIG. 19 shows the general, high-level data flow between 
the DAI 14 and the other subsystems and components of the 
present MDT invention. 

When a user lo^ onto the present invention, a Serial DAI 
(S-DAI) 14A is created to service various kinds of requests. 
All user requests from the Client 12 flow through the 
Client/Server module (CSM) 1404, which controls commu- 
nication between Client 12 and Server 32. Requests for 
metadata, both read and update (write) requests, are handled 
by the S-DAI. Read requests cause the S-DAI to query the 
Data and Schema Manipulation (DSM) module 16 for 
metadata contained in the MDT metadata tables. The S-DAI 
handles update requests by using the "Classic subsystem", a 
system for managing heirarchical data structures available 
from Bell Laboratories of Lucent Technologies. The Classic 
subsystem may be used to check and properly position new 
user segments in the segment hierarchy. The Serial DAI also 
handles requests for previously generated InfoFrames, fetch- 
ing them from the Server disk. 

When a user requests that an Analyst be generated, a 
Concurrent DAI 14B is created by the Dispatcher (if 
resources permit), and the Concurrent DAI 14B is passed all 
the information in the Analyst definition. The Concurrent 
DAI 14B then uses its built-in algorithms and metadata 
requested from the CSM 1404 to generate the InfoFrame 
which is then stored on the Server disk. 

The CSM module 1404 provides the low level services 
that pass messages from one process to another. Certain 
classes may be built on top of the CSM 1404 that make it 
easier to use, as described in further detail below. 

The message-passing design consists of 5 classes and an 
enumerated type. mdt_MessageType, the enumerated type 
has a unique value for each type of message in MDT; 

mdt TInStreamHandle and mdt_TOutStreamHandle are 

handles for incoming and outgoing message streams respec- 
tively; mdt_Message is an abstract base class for all MDT 
messages; dai_MessageHandler is an abstract base class for 
objects that can handle messages; finally, dai_ 
MessageRegistry is the registry of message handlers. 

mdt_MessageType is defined below. 



cnum mdt_MessageType { 
UNDEFINED, 
CS_LOGIN, 

SC_LOGIN_RESPONSE, 

CS_GENERATE_INFOFRAME, 

CS_GET_INFOFRAME_STATUS, 

SC_[NFOFRAME_STATUS > 

CS_GET_INFO FRAME, 

SOJNFOFRAME, 

END_OF_ENTJM 

}; 
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mdt_MessageType is an enum than defines all the mes- 
sage types understood by MDT processes. For each 
class derived from mdt_Message, there must be at 
least one value in mdt_Messageiype. This declaration 
of mdt_MessageType is used by all components of 
MDT. The message types shown are only a sample. The 
message types currently defined below are only a 
sample. This definition will evolve as MDT code is 
written. 



mdt_TInStreamHandle is defined below. 



class mdt_TInStream Handle : public csm„JnStreamHandle { 
public: 

mdt„TItiStreamHandleO : d_m type(UNDEFCNED) {} 
virtual void Connect(RWvistream "); 
mdl_MessagcTypc GeLMessageTVpeO coast; 
private; 

mdt — Mes&ageType d__mtype; 

}; 



mdt_TInStreamHandle is a typed handle for incoming 

(received) message streams. An mdt 

TInStreamHandle is used to pick up an incoming 
message stream from the CSM module 1404. The 
mdt„TInStreamHandle automatically reads the mes- 
sage's type from the incoming message stream and 
provides a member function to get that message type. 
Users of mdt__Message Registry need not use this class. 

mdt_TOutStreamHandle is defined below. 



.OutStreamHandle { 
d_mtype(t) {} 



class mdt_TOutStream Handle : public csm. 
public: 

mdt_TOutStreamHandJe(mdt_MessageType t) 
virtual void Connect(RWvostream *); 
mdt_MessagcTypc GttMcssagciypcQ const; 
private: 

mdt_TOutStrearnHandIe0; 
mdt_MessageType cLmtype; 

}; 



mdt_TOutStreamHandle is a typed handle for outgoing 
message streams. An mdt_TOutStreamHandle is used 
to send a streamed message out via the CSM 1404. The 
mdL_TOutStreamHandle has a message type and auto- 
matically writes it's message type to the stream so that 
the mdt_TInStreamHandle on the receiving end can 
decode the message type. 

mdt_Message is defined below. 



class mdt_Mc5sagc { 
public: 

mdt MessageO : d_restoreVersion(0), d_restoreFlag(faIse) {} 

mdt_^Message(const mdt_Message &); 

virtual mdt_Messageiype GetMessageTypeQ const; 

virtual int GetLatcstVcrsionO const = 0; 

virtual void SetRestoreVersion(int restore Version); 

virtual int GetRestoreVersionO const; 

virtual void saveGuts(RWvostream &) const; 

virtual void res to r eGuts (RWvis t rea m &); 

virtual bool IsRestorcdO const; 
protected: 

virtual void SetRestoredFlag(bool); 
private: 

bool d__restoreFlag; 

int d_restore Version; 

}; 



55 



Requests and Replys are communicated between Client 
12, Serial DAI 14A, Concurrent DAI 14B, Scheduler 18 and 
Dispatch 2513 by the Client/Server Module (CSM) 1404. 

CSM 1404 implements an mdt_Message class which will 
be used for sending or receiving Requests or Replies. A 
receiving mdt_Message will contain an input stream. A 
sending mdt__Message will contain an output stream. A 
stream is a well known C++ construct which allows the user 
to 'stream* the elements of a long message into a buffer, or 
to stream the elements of the message out of a buffer. 

Each of the Request and Replies implemented for the 
present MDT invention are represented by a message 
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derived frmo the mdt_Message base class and has appro- 
priate functions for streaming itself into or out of a stream. 

The CSM 1404 implements a csm_SimpleSocket and a 
csm_ServerSocket class. Each type of socket contains a 
TCP/IP socket. A TCP/IP socket is a well known API to a 
TCP/IP network. Other implementations are envisioned. 
Each type of socket can extract the stream buffer from a 
message and send it via the socket to a recieving csm_ 
Simple or csm_ServerSocket, or can receive a stream buffer 
from a sending csm_SimpleSocket and install it in a mes- 
sage. 

A csm_SimpleSocket is used to communicate messages 
between MDT subsystems in a committed, one to one 
relationship. Acsm_ServerSocket is used to allow an MDT 
subsystem to accept messages from many other subsystems. 

In FIG. 25, the Client subsystem 12 will maintain a 
csm„SimpleSocket which it will use to request a SDAI 
subsystem 2512 from the Master subsystem 2511, and which 
it will use thereafter to exchange messages with that SDAI 



Each message has a message type, a message version, and 
the ability to read/write its data from/to a stream of message 
data. For each type of message, there is a concrete imple- 
mentation of a class derived from mdt_Message. Each 
5 message class must implement GetLa test Version to return its 
version and GetMessageType to return its mdt__ 
MessageType. It must also implement the Rogue Wave 
save Guts and restore Guts methods to write its persistent 
member data to a stream and read the member data back 
10 from stream. Unpacking order is first in first out. There is 
only one derived message class per message type, but there 
can be several message types used by a derived message 
class. The same message code should be linked into both the 
sending and receiving processes. Version checking is used to 
15 robustly handle mismatches between the version of the code 
in the sending process and the receiving process. The 
message version is used by restore Guts to insure that an 
incoming message stream can be restored and to migrate 
streams saved by older versions of the class to the current 



subsystem. The Client 12 will use this socket whenever a 20 version. An mdt_3tessages is sent/received from the CSM 



user input to the Client 12 requires an exchange with the 
Server. In FIG. 25, the Master subsystem 2511 will maintain 
a csm_ServerSocket to receive messages from any Client 
subsystem 12 which wants to request an SDAI subsystem 
14A. Excepting when the Master is activly starting or 25 
otherwise tending to the SDATs, it will be listening at the 
csm_ServerSocket. 

The SDAI subsystem 2511 will maintain a csm_ 
SimpleSocket to exchange messages with the Client sub- 
system 12. Except when it is actually implementing a Client 30 
request, the SDAI 14A will be listening at its csm_ 
SimpleSocket. 

When the user 1405 submits an Analyst for immediate 
execution, the SDAI subsystem 14A will construct a new 
csm_SimpleSocket to communicate the Analyst to the Dis- 35 
patcher 2501. When the user sumbits a Scheduled or Trig- 
gered Analyst, the SDAI will construct a csm_ 
SimpleSocket to communicate the Analyst to the Scheduler 
18. The Scheduler 18 will maintain a csm__ServerSocket to 
collect Scheduled or Triggered Analysts from any and all 40 
SDAI subsystems 2511. When the Scheduler determines the 
the time has come to launch a Scheduled or Triggered 
Analyst, it will construct a csm_SimpleSocket to commu- 
nicate that Analyst to Dispatcher subsystem 2513. Except 
when it is testing its Scheduled and Triggered Analyst lists 45 
or dispatching them, the Scheduler will be listening at its 
csm_SimpleSocket. 

The Dispatcher subsystem 2513 will maintain a csm_ 
ServerSocket to collect Analysts for execution from any 
ready SDAI subsystem 2511 or from the Scheduler sub- 50 
system 18; or to collect Analyst requests from the CDAI 
subsystem 14B. When an SDAI or the Scheduler presents an 
Analyst, the Dispatch will hold it until resource become 
available for its execution. When resources are available the 
SDAI will start a CDAI 14B. When the CDAI returns a 55 
request for the Analysts, the SDAI will create a csm_ 
SimpleSocket to communicate that Analyst to the CDAI. 
Except when it is starting managing CDAIs, the SDAI 
subsytem 2513 will be listening at its csm__ServerSocket. 

The CDAI subsystem 14B will construct a csm_ 60 
SimpleSocket shortly after it is started to collect its Analyst 
from the Dispatcher subsystem 2513. After collecting this 
message, it will discard the csm__SimpleSocket. The CDAI 
14B will exchange no other messages with the other sub- 
systems of the present invention. 65 

The mdt_Message abstract base class defines the object 
that holds the content of an MDT interprocess message. 



module 1404 by saving/restoring its guts to/from the stream 
pointed to by the mdt__TOutStreamHandle/mdt__ 
TInStreamHandle class defined above. 
dai_MessageHandler is defined below. 



dai_MessageHandler is defined below, 
class daL^MessageHandler { 
public: 

virtual bool HandleMessage(const mdt_Message &) ■ 

}; 



dai_MessageHandler is an abstract base class for mes- 
sage handler classes. If the process uses the message 
registry to dispatch received messages, at least one 
concrete message handler class must be implemented. 
As many as one message handler per registered mes- 
sage may be implemented. 

dai_MessageRegistry is defined below. 



class dai_MessageRegistry { 
public: 

dai_McssagcRcgistry( csm_Conncct &); 

void DispatchMessageQ; 

void RegisterMessage(mdt MessageType, 

daL.MessagcCrcateFmic, 
dai__MessageHandler &); 

private: 

dai MessageCreateFunc d createFunc; 

dai MessageHandler *d_handler; 

csm_Connect *d connect; 

}; 



dai_MessageRegistry is a class meant to be instantiated 
only once in each process that uses it. The message 
registry provides a method to register a handler for each 
message type and a method to dispatch all incoming 
methods. The dispatch method acts as the application's 
main loop. The return value of the HandleMessage 
method of the handler determines whether Dispatch- 
Messages blocks or returns after a message is pro- 
cessed. If the return value is true, it blocks. 
The following is the set of events that occur as a message 
is transmitted from one process to another using the MDT 
typed stream handles and the message registry. 

1. sending process constructs an instance of a concrete 
message class (derived from mdt_Message), MS and 
loads it with the proper message data. 
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2. sending process creates an mdt_TOutStrearaHandle a schedule. Otherwise it executes right away. InfoFrames 
object with the same message type as the message. The contain a variety of kinds of business data and hyperlinks 
mdt_TOutStreamHandle object writes the message which can be used to run other Analysts and generate related 
type to the stream. InfoFrames. The functionality of MDT, including Analyst 

3. sending process uses the message's saveGuts member 5 definition and InfoFrame generation, requires an "MDT 
function to write the message to the message stream. view" of the data warehouse 24 that we refer to as "MDT 

4. message's saveGuts method first calls base class metadata" 25. 

method which writes the message's version number to ™* word "metadata", in general refers to various kinds, 

the stream. Next it saves the message's persistent f " da * a abo * data " in » or data warehouse 24 

member data fields to the stream. 10 ( FIG * MDT metadata 25 provides a customizable view of 

5 sendin process calls csm tne data not restricted by the relational structure of the 

" JT , n 1 3 t P x . . ~ database. MDT metadata 25 is stored in the data warehouse 

SendProcessConnect::Send( ) to send the message A . L1 , . , , 

stream 24 as a set of tables and is read by MDT present invention 

during start-up. Populating the metadata 25 in the warehouse 

6. The CSM extracts bytes from the stream object and 15 24 is * kcy part of thc MDT instaU ation process, and an 
sends the bytes to the receiving process. MDT Administrator will generally be needed to extend and 

7. When the mdt_TOutStreamHandle object is destroyed, maintain the MDT metadata using knowledge of the struc- 
it in turn destroys the stream object it was connected to. mre 0 f tnc data warehouse 24. 

8. The receiving process should be waiting in a call to There are 4 main kinds of MDT metadata: (1) Dimensions 
csm_ReceiveProcess::Receive( ). Internally, there is 20 and Attributes, (2) Segments and Partitions, (3) Measures, 
probably some queuing of messages. and (4) Measure Relationships. The present specification 

9. The CSM in the receiving process gets the oldest describes each kind of Metadata with a series of tables. Each 
queued message. It then converts the bytes into a table shows the column names and the types of the data 
stream object and connects that stream to the mdt_ values in that column (in parentheses). Some columns define 
TInStreamHandle object that was passed to csm_ 25 MDT-oriented entities or objects, and others provide map- 
ReceiveProcess::Receive( ). ping information between MDT metadata and the relational 

10. When the stream is connected to the handle, the schema of the warehouse. Primary keys for each table are 
handle reads the message type from the stream and italicized (if more than one column name is italicized, the 
remembers it combination of those column names forms the key). 

11. Finally! control returns from csm_ 30 MDT metadata 25 includes an explicit notion that certain 

ReceiveProcess: : Receive( ) to the caller. data at ' nbu,es have a J fimte * t ° f ™ lueS " a u re 

<n ^ . . ; 4 , c iL referred to as enumerated attributes . For example, the 

12. The receiving process gets the message type from the ^ ent ^ £ac , ^ ^ for 

mdt_TInS t reamHandle and constructs an empty ^ ..^ m t£) a ^ ^ of yalues (tha , 

jnstance of the right type of message class for that 3$ ^ rf ^ 5Q sutes rf ^ United s ^ whatever 

message type If the message dispatcher is m use this ^ data warehouse „ ses) ^ MDX metadata 

It n . ( ail n e 4LU y , v ai ~~ tables also refer to, for convenience, sets of values that are 

Mes S ageRegistry::DispatchMessages( ). represented in enumerated types in source code header files. 

13. The receiving process calls the message's restoreGuts The WQrd « enum « refers to coUram values of this type- 
function. If the message dispatcher is in use, this is ^ ^ uble repr esentation of MDT metadata 25 is first 
handled by dai_MessageRegistry : :Dispatch described in 4 sections, one for each main kind of Metadata. 
Messages( ). j^iq following are then described: representation of time in 

14. The message's restoreGuts method first calls the MDT, the kinds of metadata that need to be stored in source 
restoreGuts method of its base class (usually mdt_ ^de header files, and the issue of populating the metadata 
Message) which reads the version number and saves it 45 tables during installation is discussed, 

as the Res to reversion member. Next control returns to Dimensions are the starting vocabulary for the domain: 

the derived version of restoreGuts. It calls GetRestor- they define the high-level categories of entities. For 

e Version and uses the resulting version number to example, in a retail domain, the Dimensions might be: 

determine which data members to read from the stream Product, Market, and Time (Time is a universal Dimensions 

and what order to read them in. Next the data fields of 50 applicable to most domains and is discussed in a later 

the message class are read back from the stream. section). Each Dimension has a set of attributes that can be 

15. The received message is now in its final form. If the used to describe its entities; for example, the various 
dispatcher is in use, it looks up the handler for this attributes for Product, like Department, Price, Style, and 
message type in the registry and calls its HandleMes- Manufacturer, 

sage method. 55 All tables in this section are set up during installation and 

16. When the mdt_TInStreamHandle object used to are unlikely to change often, because they are all heavily 
receive the message is destroyed (or reconnected by dependent on the structure of the data warehouse 24 and the 
another call to csm_ReceiveProcess::Receive( ), the industry-specific view of the data. None of the tables in this 
stream it was pointing to is deleted. section are generally modifiable by the end user, although 

The present MDT invention enables business or other 60 occasional modification may be needed by the MDT Admin- 
users to monitor their data warehouse 24 by defining pow- istrator to extend MDT metadata or respond to changes in 
erful report-generation objects called Analysts. An Analyst the relational schema of the data warehouse, 
is an encapsulation of a generic type of business analysis, As shown in the following table, dimensions are repre- 
customized by the user 1405 by providing a set of sen ted by their name and an associated Id. The Id is used to 
parameters, a schedule, and a trigger condition. The Analyst 65 join with other tables more efficiently. The Seg-Id is the Id 
periodically checks the trigger condition if it has a trigger of the top-level segment for this dimension, and the Corn- 
condition, or periodically executes on the schedule if it has ment is a comment. 



08/28/2002, EAST Version: 1.03.0002 



47 



5,870,746 



48 



7256jDi 








m-Id 


Name 


Seg-Id 


Comment 


(int) 


(string) 


(int) 


(string) 


001 


Product 






002 


Market 







The following table represents all of the attributes for 
each Dimension. Each attribute has a unique Id (Attr-Id), a 
name, and the Id (Dim-Id) of the Dimension they belong to. 
Attributes for different Dimensions can have the same name 
(but they will have different Ids). MDT-Type indicates the 
MDT type of the attribute. Each attribute is mapped to a 
single table and column, and we encode the data type of the 
field in the database that each attribute maps to (Column- 
Type). All the attributes for a given Dimension can be 
extracted from this table using the Dim-Id field. The enum 
values for MDT-Type are: enum, int, float, restricted- int, 
restricted-float, string. The enum values for Column-Type 
are all those types supported by the data warehouse. 





Attr-Id 


Min 


Max 




(int) 


(float) 


(float) 


5 


"income" 


0 


1000.00 



A key part of the MDT metadata 25 are a set of segments 
and partitions for each Dimension. A segment is a set of 
attribute restrictions that define a class of objects of interest. 

10 For example, "Stores remodeled less than one year ago", or 
"non-seasonal store -wide promotions", or "Perry-Ellis shirts 
of size 14 and larger". Segments are arranged in hierarchies, 
one for each Dimension. The hierarchies are further orga- 
nized using the concept of a partition: a set of related 

15 segments differing only by the restriction on a single 
attribute. Segments and partitions are represented by a set of 
tables that capture the segment/partition hierarchy for each 
Dimension and define the attribute restrictions for each 
table. 

20 The following table names each segment and the Dimen- 
sions it is a part of, and provides the name and the owner of 
the segment. The Owner string for segments that are glo- 



Attr-Id 
(int) 


Name 
(string) 


Dim-Id 
(int) 


MDT-Typ< 
(enum) 


006 


Manufacturer 


001 


enum 


016 


Size 


001 


int 


0057 


Region 


002 


enum 


017 


Department 


001 


enum 


0099 


Size 


002 


float 



Table Column Column- Type 
(string) (string) (enum) 



Comment 
(string) 



With respect to attributes that are enumerated types, the 
following table represents the legitimate values for these 
attributes. These values will have both a user name, like 
"Men's Clothing" and the name of the actual data value, like 
"Dept-017". The information in these tables can be partially 
generated by a "Select . . . Distinct ..." query for the 
attribute. 



35 bally owned will be defined in a header file; here and 
elsewhere it is shown as "ALL". There is a so-called 
"top-level segment" for each Dimension with the name "All 
X", where X is the Dimension name. The Num-Attrs field 
contains the number of attributes used to restrict this seg- 

40 ment. For the "top-level segments", Num-Attrs will be equal 
to 0. 



Attr-Id 


Display-Name 


Data- Name 


(int) 


(string) 


(string) 


0017 


Men's Clothing 


Dept-017 


0017 


Housewares 




0017 


Hardware 




0057 


Southern 





45 



For attributes that have type integer, the following table 
defines the appropriate ranges of values and a "typical 
value" if this would be useful to present to the user. Not all 
integer attributes have to appear in this table, if they do not 
have natural ranges and typical values. 



Seg-Id Dim- Id Name Owner Num-Attrs Comment 

(int) (int) (string) (string) (int) (string) 



112 


001 


Men's Clothing 


ALL 


26 


001 


Men's Shirts 


ALL 


14 


001 


Perry-Ellis Shirts 


Pgs 


117 


001 


Perry-Ellis Men's 


PS 8 






Shirts 













The following table represents all the numeric attribute 

Attr-ld Mm Max restrictions for each segment represented in the following 

(int) (int) (int) interval notation. In the first row above, if Attr-Id 017 stands 

~ age » 0 120 60 for the Attribute "Size", then this row would read: "0<« 

Size<-100"; that is, "Size is greater than 0 and less than 

For attributes that have type float, the following table 100 "- Valucs m ^presented as Strings so restrictions of 

defines the appropriate ranges of values and a "typical attributes of other type (like float or currency) can also be 

value" if this would be useful to present to the user. Not all 65 represented. The enum values of Operator-1 are: greater 

float attributes have to appear in this table, if they do not than, less than, greater than or is, less than or is, is, is not, 

have natural ranges and typical values. is between. 
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Scg-Id 


Attr-Id 


Value- 1 


Operator- 1 


\fclue-2 


(int) 


(int) 


(float) 


(enum) 


(float) 


112 


017 


0 


"between" 


100 


112 


018 








14 










117 





















The following table represents all the set or enumerated 
type attribute restrictions for each segment. The The "Data 
Name" column is the same as before. For example, one 
might represent the segment "East Coast Cities" and define 
it as the set {New York, Boston, Washington, . . . }. To do 
this, several entries, one for each city, would appear in this 
table. This table can also be used to represent string attribute 
restrictions. The enum values for Operator are: is, is not, is 
in list, not in list. 



Seg-Id 


Attr-Id 


Operator 


Data Name 


(int) 


(int) 


(enum) 


(string) 


112 


019 


"in list" 


Seattle 


112 








14 








117 

















10 



15 



20 



25 



The following table defines each partition and the 
attribute it is defined over. Hie default partition name is that 
same as that of the attribute it is' defined over. In this case, 
the user interface will display the partition name by append- 
ing "by-" as a prefix. The Name can be updated by the user 
1405. 



Prtn-Id 


Seg-Id 


(int) 


(int) 


19 


15 


221 


222 







Measures are values in the data warehouse 24 that can be 
measured over the data. For example, Sales, Price, and 
Market Share are all measures in the retail domain. Different 
Measures are "rolled up" differently; for example, Sales over 
several markets are added while Market Share is averaged. 
The present MDT invention provides a set of Basic Mea- 
sures during installation and allows the user to combine 
them to form more complicated Composite Measures using 
formulas. 

The following table names the Measure, defines its rollup 
mechanism, and maps the Measure to a table and column. 
The Display Units column is for InfoFrame generation only. 
Precision is the number of digits needed to the right of the 
decimal point. The enum values for Rollup are: add, 
average, count. 



30 



BM-Id 
(int) 


Name 
(string) 


Rollup 
(enum) 


T^ble 
(string) 


Column 
(string) 


Display 
units 
(string) 


Precision 
(int) 


Comment 
(string) 


055 
0917 


Sales 
Discount factor 


add 
average 













Prtn-Id 


Name 


Owner 


Attr-Id 


(int) 


(string) 


(string) 


(int) 


59 




ALL 


0059 


117 




Pgs 


0017 











45 



50 



The following table and the next define the segment/ 
partition hierarchy. This table represents the child partitions 
of each segment. This table can also be used to find the 
parent segments for a given partition. 



Seg-Id 


Prtn-Id 


(int) 


(int) 


112 


59 


13 


117 
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The following table represents child segments for each 
partition. This table can also be used to find the parent 
partitions for each segment. 



Composite measures are built by combing basic 
measures, certain binary and unary operations, and special 
keywords that indicate, for example, the target segment, the 
child segments of a partition, or the sibling segments of a 
target segment. In addition, one can encode a set of segments 
to restrict a measure, using the next table. The Left-Arg and 
Right-Arg encode the kind of argument in "Left-M" or 
"Rigbt-M", as shown here: 

1. Basic measure 

2. Composite measure 

3. "Target segment" 

4. "Parent segment" 

5. Segment list: 2d argument is the Slist index (see next 
table). 

6. Sibling segments 

7. Child segments 

If the operator in Op is a unary operator (count, sum, 
average), then only the Left-M is used. If the operator in Op 
is a binary operator (+, -, etc.), then both the Left-M and 
Right-M are used. 
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CM-Id Owner Name Display Left-M Left-Arg Op Right-M Right- 
(int) (string) (string) Unite (int) type (enum) (int) Arg type 
(string) (enum) (enum) 



If the Composite Measure references a list of segments, 
then the elements of the list are represented in the following 
table. 



Cm-Id 


Seg-Ed 


(int) 


(int) 


17 


5 


17 


6 



The following table is used to join an attribute with a basic 
measure to evaluate a dimensional query. The idea is that, 
for each attribute (that maps to a table and a column) and for 
each measure (that also maps to a table and a column), you 
need to be able to join their two tables. This table gives the 
column names for the two equivalent columns (keys) that 
can be used in the join. 



Attr-Id 


Bin-Id 


Attr-Column 


BM-Column 


(int) 


(int) 


(string) 


(string) 


5 


8 


"cust_age" 


* , mkt_share" 



The following table is used to join two attributes together 
to evaluate a dimensional query. That is, if the previous table 
(above) is not sufficient to join all attributes in a dimensional 
query to the measure, this table can be searched to try to find 
a path of attributes that can be used to create multiple joins 
to combine all attribute tables with all measure tables. 



Attil-td 

(int) 


Attr2-Id 
(int) 


Attrl - Column Attr2- Co lumn 
(string) (string) 


17 


4 


"cust_age" "age" 



A Measure Relationship is a qualitative description of 
causality between Measures. For example, in general, if 
"Shelf Space" for a product goes up, then one would expect 
"Sales" to go up as well. In this example, "Shelf Space" is 
the independent Measure and "Sales" is the dependent 
measure. However, Measure Relationships are more com- 
plicated than a simple statement of causality and direction. 
One would not expect the above example to hold over all 
values of "Shelf Space" but only some range of values. 
Similarly, one might expect the relationship to hold only if 
the "Shelf Space" increased by some reasonable percent. 
Also, one might expect a measure relationship to hold only 
for some segments but not for others. 

The following table defines basic Measure Relationships 
as follows. The value for the column I -Direction is either 
"direct" or "inverse", an enumerated type defined in a header 
file. If the value is "direct", then if the Independent Measure 
goes up, the Dependent Measure should go up. If the value 
is "inverse", then if the Independent Measure goes up, the 
Dependent Measure should go down. The enum values for 
I-Direction are: direct, inverse. 



10 MR-Id 


Owner 


Indepedent M-Id 


[-Direction 


Dependent M-Id 


(int) 


(string) 


(int) 


(enum) 


(int) 


019 


PGS 


5 


"direct" 


21 



15 



The following table restricts the Measure Relationship to 
a certain range of values of the Independent Measure. The 
Operation can be >, <, >-, <-, not-, or between. For 
20 between, both Value -1 and Value-2 are used. The enum 
values for Operation are: is less than, is greater than, is less 
than or =, is greater than or =, is, is not, between, not 
between. 



MR-Id 


Operation 


Value- 1 


Value-2 


(int) 


(enum) 


(float) 


(float) 


019 


"between" 


5 


100 



30 



The following table applies only to Measure Relation- 
ships with the Change Analysis Analyst definitions. It 
restricts the Measure Relationship to apply only when the 
Independent Measure changes appropriately over the time 
period of the Change Analysis. Hie enum values for Direc- 
tion are: increases, decreases. 



MR-Id Direction Value Unit 

40 (int) (enum) (float) (string) 



The following table restricts the applicability of Measure 
Relations by segment. Note that if a Measure Relation 
45 applies to a given segment, it will also apply to all children 
segments. 





MR-Id 


Seg-Id 


50 


(int) 


(int) 




055 


19 









55 Time is an important part of MDT metadata 25. At one 
level, we would like the user to think of Tune as another 
Dimension; however, because Time segments can be created 
on-the-fly (for example, the segment "Year-to-Date"), they 
are represented differently. We show this representation as a 

60 set of tables, although some of the information may be 
defined in source code header files. 

The following table defines the lowest unit of granularity 
of time represented in the data warehouse 24. We are 

65 assuming that all representations of time in the data ware- 
house uses this single unit of time. The enum values for Base 
Unit are: day, week, month, year. 
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Base Unit 
(enum) 

Day 5 



If a database table is used by a measure, that table must 
have a column for time in it. The following table lists the 
columns for each table that represent time, for each basic 
measure. 



Table 


BM-Id 


Column 


(string) 


(int) 


(string) 


Transaction 




Time-stamp 



15 



The following table defines the different notions of year 
that may be important to the user 1405. The enum values for 
Week Start Day are: Sunday, Monday, Tuesday, . . . , 20 
Saturday. 
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[step 2101] The Client 12 sends a metadata request 
message to the S-DAI 14AA, This message includes 
the the message type and the required parameters. 

[step 2102] The Serial DAI 14A examines the message 
type and determines which Metadata table 25 is 
needed. 

[step 2103] Using the parameters, the S-DAI scans the 
Metadata table(s) 25 for the correct metadata. 

[step 2104] The Serial DAI 14A packages the metadata 
up. 

[step 2105] The Serial DAI 14A sends a metadata mes- 
sage back to the Client 12. 

In the unlikely event of an error, the S-DAI 14A will log 
the error in the server error log and return an error code to 
the Client 12. There may be several kinds of errors of 
varying severity. 

New Composite Measures are added from the Client 12 
using the user interface. Any syntactic or semantic checking 
will take place there. The syntax for Composite Measures is 
shown above. When the Client 12 indicates that a new 
Composite measure has been created, the Serial DAI will 



Name 


Start Month 


Start Day 


Start Day 


Comment 


(string) 


(string) 


(int) 


(enum) 


(string) 


Calendar 


January 








Fiscal 


May 








Jan Feb 


Mar Apr May 


Jun July 


Aug Sept Oct 


Nov Dec 


Start Start 


Start Start Start 


Start Start 


Start Start Start 


Start Start 



(int) (int) (int) (int) (int) (int) (int) (int) (int) (int) (int) (int) 



Quarter 1 Quarter 1 Quarter 2 Quarter 2 QuarteT 3 Quarter 3 Quarter 4 Quarter 4 

Begin Begin Begin Begin Begin Begin Begin Begin 

Month Day Month Day Month Day Month Day 

(int) (int) (int) (int) (int) (int) (int) (int) 



The Serial DAI (S-DAI) 14A (FIG. 19) is responsible for 
providing access to MDT metadata 25 to each Client 12. ^ 
When a Client 12 logs into MDT, a Serial DAI 14A is 
created and connected to the Client session. All Client 
requests for metadata, including update requests, are 
handled by the Serial DAI 14A. In addition, the S-DAI 14A 
provides access to the MDT Administrator, allowing him or 
her to configure MDT using the setup screens. 45 

The architecture of the Serial DAI is shown in FIG. 20. 

The Serial DAI 14A gets requests in the form of MDT 
messages from the Client 12. Each MDT message has its 
own "reply class" in the S-DAI 14A. Messages for metadata 
access and simple update are handled through the Metadata 50 
table interface of the DSM 16 (that is, without using the 
Classic component 14AA — defined further below). 
Requests to add or delete segments use the Classic compo- 
nent 14AA to validate the request and update the hierarchy 
as needed. ss 

Metadata access and simple update services are provided 
to the Client 12 by the Serial DAI 14A without use of the 
Classic component 14AA. Whenever the Client 12 needs a 
particular piece of Metadata, typically to present in the user 
interface, the Client 12 will send a request message to the 
S-DAI 14A. The S-DAI 14A will access the appropriate 60 
Metadata tables 25 to extract the appropriate Metadata. It 
will then package it up and return it to the Client 12 in one 
or more messages. The Metadata interface automatically 
provides access to public metadata and the metadata for this 
particular user. 65 

The general flow of data and control is shown in FIG. 21 
and described below. 



add the information to the appropriate metadata table, dis- 
cussed previously. 

An existing Composite Measure can be updated by pull- 
ing up an existing measure in the Measure Builder screen, 
editing it, and hitting the Save button. The edited Composite 
Measure will be saved to the Metadata tables 25 using the 
same Composite Measure Id. The Client 12 will display a 
warning message to the user 1405 to the effect that, if this 
Measure is being used in an Analyst, the meaning of the 
results presented in the subsequent Info Frame will be dif- 
ferent. 

A Composite Measure can be deleted if it is owned by the 
user. The Composite Measure and its formula entries will be 
deleted from the appropriate table, previously described. A 
warning message will be presented to the user 1405, warning 
that if this Compound Measure is used by any Analyst or 
other Compound Measure, the subsequent InfoFrame will 
not be generated correctly and an "analyst-time" error will 
occur. 

Adding a new measure relationship is similar to adding a 
new Composite measure. All checking, if any, will take 
place in the Client 12. When the Client indicates that a new 
measure relationship has been created, the Serial DAI 14A 
will add the information to the appropriate metadata tables. 

Modifying a measure relationship is straightforward. The 
appropriate tables are updated and the measure relationship 
id is preserved. A Measure Relationship can be deleted if it 
is owned by the user 1405. The Measure Relationship and its 
table entries will be deleted from the appropriate tables. A 
warning message will be presented to the user, warning that 
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if this Measure Relationship is used by an Analyst, the 
subsequent InfoFrame will not be complete and an "analyst- 
time" error will occur. 

Hie Serial DAI 14A also processes requests from the 
MDT administrator. These requests are used to install MDT 
and make occasional changes to the public metadata. The 
Serial DAI 14A must handle the flow of information from 
both the data warehouse 24 to the Client 12 (sending both 
data warehouse schema information and metadata) and from 
the Client 12 to the data warehouse 24, in this case exclu- 
sively to the metadata. The Serial DAI 14A is not expected 
to have to do any processing on the data itself, i.e., to do 
additional integrity or exception checking. 

The data warehouse schema is passed to the Client 12 in 
one uninterpretted bundle and the Client 12 will interpret it. 
There are eight steps to setting up or installing MDT. Each 
step involves the Client 12 getting information from the 
Administrator through the user interface and passing infor- 
mation to the S-DAI 14A. The S-DAI 14A will update the 
metadata tables through the DSM interface. These steps are: 

1. define dimensions 

2. define and map attributes to database columns 

3. rename coded attribute values 

4. create basic segments 

5. define and map basic measures to database columns 

6. review the joins between database tables 

7. assign database columns as time markers 

8. define year types 

Classic 14AA is used to represent the user's segment and 
partition hierarchy, as described previously. When a user 
adds, modifies, or deletes a segment, the Classic component 
14AA determines any and all changes that need to be made 
to the segment/partition hierarchy, or detects one of several 
possible kinds of errors. If there are no errors, these changes 
are then used to update the Client interface and the persistent 
metadata tables. This is shown in FIG. 22: 
[step 2201] The Client 12 sends a segment update request, 

either an add, delete, or modify segment message, 
[step 2202] The S-DAI receives the request, 
[step 2203] It then calls the appropriate function in the 
Classic module, which uses Classic to determine all of 
the segment/partition changes the request induces, 
[step 2004] These changes (or an appropriate error 
condition) are returned; if there is an error, this is 
passed back to the Client with no changes to the 
Metadata tables, 
[step 2205] If there is no error, all changes are passed to 

the Metadata tables, 
[step 2206] Again, assuming no errors, an acknowledge 

message is sent to the Client, 
[step 2207] If the knowledge base is changed, the appro- 
priate knowledge base file is updated. 
Hie user's segment hierarchy is kept persistent in a 
knowledge base files on the Server disk. This is because it 
would be too time-consuming to re-create it each and every 
time from the Metadata tables. There is one knowledge base 
file for each dimension and each user. Each file reside in 
some area on the Server disk and be named "dimension, 
user". 

The user 1405 adds a new segment by selecting an 
existing segment (perhaps the top level segment) and then 
selecting a sequence of attributes and restrictions. This 
sequence defines a sequence of partitions and attributes. 
Consider the set of attributes and restrictions of: {ago 65, 
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income>100K}. This segment might be called "Wealthy 
Seniors". This would give rise to the following sequence, 
assuming the segment was defined at the top level: 

5 

All Customeis 

[By-Age] <- partition named by its attribute 

Age>65 <- automatically named intermediate egment 

[By- Income] 

Wealthy Seniors <- user-defined and named segment 

10 

The order of attributes is very important. That is, the final 
segment, "Wealthy Seniors", could also have been defined 
by Income and then by Age, with the same resulting final 
segment. However, the automatically created intermediate 
15 segment, and the two automatically created partitions, would 
be different. (In this case, the first partition would be 
"By-Income", the intermediate segment would be 
"IncomolOO", and the second partition would be "By- 
Age"). 

20 The following guidelines are supported for the creating of 
new segments: 

1 . The final user-named segment is created 

2. "Supporting" partitions and segments are automatically 
created and named but only in the attribute order 

25 generated by the user 1405 

3. If the final segment is a child of any existing partition 
it "appears there" as well 

4. If the final segment differs by a single attribute from an 
existing segment, the one intermediate supporting par- 

30 tition will be created. 

5. If any segments are classified under the new segment 
and differ by just one attribute, the appropriate partition 
is created. 

To illustrate guideline 4 above, let us assume the Cus- 
35 tomer hierarchy looks like this: 



All Customers 
[By-Income] 

Moderate-Income 
High-Income 



The user defines "Wealthy Seniors" as above. The hier- 
archy should now look like this: 

45 

All Customers 
[By-Age] 
Age>65 

[By- Income] 
5Q Wealthy Seniors 

[By- Income] 

Moderate-Income 
High-Income 
[By-Age] 

Wealthy Seniors <- segment and partition 
automatically added 



Likewise, when the user 1405 adds a new segment, if 
there is an existing segment that belongs under that segment, 
differing by a single attribute, the existing segment will be 
60 put under the new segment and the new partition will be 
created. 

The segment/partition hierarchy is somewhat of a strange 
beast. It is rooted at the "top-level segment" for that 
dimension, which is a segment with no attribute restrictions 
65 (this is why it represents "ALL-X", where X is the 
dimension, like Customer or Product). Each segment has a 
number of child partitions. Each partition represents a seg- 
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mentation by a single attribute and has a number of child 
segments. A segment can belong to several partitions. A 
partition has only one parent segment. 

The user 1405 creates a new segment by selecting a 
starting or parent segment, choosing a name for the final 
segment, and then entering a set of attributes and restrictions 
in the user interface. For each attribute restriction (in the 
order the user chose) a segment will be created and added to 
the segment/partition hierarchy. When a segment is added, 
partitions may need to be created both above and below the 
new segment. 

FIG. 23 shows the addition of a segment (without loss of 
generality, one that differs from its parent by one attribute 
restriction). First, the new segment must be "fit" with a 
partition underneath its specified parent. If the new segment 
fits in an existing partition or partitions, it is added to those 
partitions (reference numeral 2301). If not, a new partition 
is created, (reference numeral 2302), As with all new 
partitions, other segments may fit and be added. For all other 
parents of the new segment (Classic will tell us all parents), 
we first make sure the new segment and parent differ by only 
1 attribute. If so, as is true of the parent at reference numeral 
2303, we again add to existing partitions (reference numeral 
2304) or create a new one. (The Parent at reference numeral 
2305 differs by more than one attribute. This means we don't 
know the order of the intervening segments, so we leave it 
alone.) Finally, any children segments of the new segment 
(like reference numeral 2306) (Classic will tell us the 
children of a segment) are fitted with new or existing 
partitions, like reference numeral 2307. 

The following is a very brief sketch of the algorithm for 
adding a new segment to a user's hierarchy. When Classic 
14AA is used, this is indicated by underlining. 

INPUT: a parent segment and a new segment (NEW). The 
new segment consists of a single added attribute restriction. 
When the user 1405 inputs more than one attribute 
restriction, this basic algorithm is called several times, with 
names generated for the intermediate segments. 



greate a temporary Classic segment for NEW 
If NEW is identical to an existing segment return 
/* for each parent: 

check that the level difference is one 

cither add the segment to an existing partition or 

create a partition, add the segment, then add additional segments 

*/ 

get the parent seements of NEW 
for each Parent { 

if the level difference «»1 { 
fits_flag - FALSE; 

for each child partition of this segment { 
If the segment fits in this partition f 
fUs_jlag = TRUE; 
add the segment to the partition 

} 

if (!fits_flag) { 

create a new partition under the parent 
add the segment to the partition 
for all other children of the current parent { 
if the child fits this new partition 
add it to the partition 

} 

} 

} 

} 

/* Now that the segment has been added to all its parents: 
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For all children of the new segment: 



check to see the level difference is 1 
either add it to an existing partition or 
5 create one 

V 

Get the children of the segment NEW 
For each child { 

if the level difference 1 { 
for each child partition of NEW { 
10 if child fits with partition { 

add it to the partition 
fits_Jlflg = TRUE 

} 

else { 

create a new partition under NEW 
15 add the child to it 

} 

} 

} 



20 Deleting a segment can be surprisingly tricky. That is 
because various changes in the hierarchy can occur when a 
single segment is deleted. By design, we require that chil- 
dren of a segment to be deleted are themselves deleted if no 
other partitions refer to them. 
With reference to FIG. 24: 

25 



FOR ALL PARENT PARTITIONS 

[2401] remove the parent/segment link 
[24021 if no other segment, delete the partition 
FOR ALL CHILDREN OF THE PARENT SEGMENT 
30 [2404] see if they "fit" the partition now 

FOR ALL PARENT PARTITIONS 

[2405] see if they are redundant and can be "collapsed" 
FOR ALL CHILD PARTITIONS 

[2406] remove the segment/partition link 
[2407] delete the partition 
35 FOR ALL CHILD SEGMENTS 

[2408] delete the child segment link 
[2409] if they have no parent partition, DELETE 
[2410] DELETE THE SEGMENT 



40 Mention was previously made of an "other" segment 
(referred to herein as "OS") that represents those entities not 
captured by the explicit segments in the final partition. For 
example, in a hierarchy that looks like this: 



All Customers 
[By-Age] 
Age>65 

[By-Income] 

Wealthy Seniors 

50 

the OS under the partition "By-Income" would represent 
people older than 65 but whose income does not make them 
wealthy. 

The OS will not be represented explicitly in the hierarchy. 

55 This is because its definition will change depending on what 
segments exist. For example, if the user added a segment 
called "Middle class seniors", the definition of the OS would 
change. Rather, the OS is implicit and its attribute restric- 
tions can be computed by taking the restrictions of its sibling 

60 segments and negating them. 

The Classic knowledge base must be initialized from the 
persistent metadata tables 25, either when a user 1405 first 
logs in or when a segment update request is received. Each 
dimension and its respective segments and partitions can be 

65 treated as a separate knowledge base. The initialization can 
be performed in two ways: (1) by making direct calls to 
Classic 14AA, or (2) by creating an ASCII flat file that 



08/28/2002, EAST Version: 1.03.0002 



5,870/ 

59 

Classic 14AA can read. The former is probably more 
efficient, while the latter may have advantages for debugging 
and retraction on error. 

The general steps to create a Classic knowedge base are 
as follows, with reference to the table previously defined: 5 



• For each Dimension, read from the Dimension Definition table 
»> define a dimcnsion_Jil!er individual for that Dimension 
«> For each numeric or string attribute 

0 define the attribute role jo 
«*> For each enumerated attribute 

0 define the attribute role 

0 define the primitive "filler" 

O for each enumerated attribute value 
* define the value individual 
«> For each segment definition ^ 

O get all the attribute restrictions 

0 define the segment 

0 define the segment individual 
-> For all partitions 

0 aeate a partition individual 
=> For all Segment to Child Partition mapping 

0 create the mapping by adding the partition individual to the ^ 
segment individual 
-> For all Partition to Child Segment mapping 

0 create the mapping by adding the segment individual to the 
partition individual 



The modification of metadata, including the addition, 
deletion, and editing (changing) of metadata by both MDT 
Business-level users and the MDT Administrator (or Analyst 
level user), will now be described. 

To modify metadata means to change it. In one 
embodiment, there are three kinds of change supported by 
the Serial DAI 14A and the Client interface: addition, 
deletion, and editing. The kinds of metadata involved typi- 
cally include segments, composite measures, and measure 
relationships. There are two kinds of users 1405 who modify 
metadata: normal (or "business level" users), and the MDT 
Administrator or Analyst Level user, both refered to in this 
document as the MDTA The MDTA can usually, but not 
always, be thought of as another user editing public meta- 
data. We are generally not concerned here with the MDTA 
changing other kinds of MDT metadata like the mapping and 
join information. The table below summarizes these com- 
binations: 



Subject 


Action 


Object 


User 


Add 


Segments 


MDTA 


Delete 


Composite Measures 




Edit 


Measure 






Relationships 


MDTA 


Add 


Dimensions 




Delete 


Attributes 






Basic Measures 



45 



Modification of metadata is done through the Client 
interface, including the segment builder, measure builder, 55 
measure relationship builder, and some setup screens. The 
general flow of control is from the Client 12 to the Serial 
DAI (S-DAI) 14A, to the Classic component 14AA if 
segments are involved, and then to the metadata tables 25. 
Various warnings and errors may be presented to the user 60 
1405, as appropriate. 

Modification of metadata gets tricky for two reasons. 
First, their exist dependencies between metadata, for 
example, between segments and composite measures that 
refer to a segment, or dependencies between "public" meta- 65 
data managed by the MDTA and various user J s private 
metadata. Second, defined analysts, either scheduled or 
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unscheduled, may refer to metadata that has been modified. 
Several important issues must be addressed, for example: 

1. What happens when an analyst refers to missing 
metadata, i.e., metadata that has been deleted? 

2. What happens when metadata is deleted and other 
metadata refers to it? 

3. When the MDTA changes public segments, how are the 
user's segment hierarchies updated? 

4. What happens when the MDTA deletes a dimension, 
attribute, or basic measure? 

One can imagine two extreme approaches along a spec- 
trum: one, do no checking whatsoever (a "user beware" 
approach), two, try to capture and prevent all potential 
problems. In a preferred embodiment, the present invention 
may be designed to be closer to the "user beware" side of the 
spectrum, although any other suitable design may be imple- 
mented. Given this, it is desirable to give the user 1405 
warnings and information when available and to not do 
anything that surprises the user 1405 without warning and, 
if possible, confirmation. 

The Concurrent DAI (CDAI) 14B (FIG. 19) is the MDT 
subsystem that generates InfoFrames. Its input is an InfoF- 
rame Request from the Client 12 or Scheduler subsystems 
18 and its output is an InfoFrame containing an external 
HTML text report contained in a file in the User Return 
Area. The working of the CDAI subsystem 14B, including 
how it is structured and the format of the resulting reports, 
are provided below. 

The CDAI 14B may be a UNIX or NT process executing 
on the UNIX or NT Server platform. It is invoked by a 
Dispatcher component with the command line such as: 

mdtquery engine [~c <config>] [-e <err!og>] 

where the config name and the errlog name are optional 
Configuration file and Error Log names respectively, inher- 
ited by the Dispatcher from the Master's command line 
when the Master invokes it. 

Certain features of the CDATs 14B function may be 
determined by the value of attributes defined in a Configu- 
ration file. These attribute values specify the thresholds for 
Interestingness Heuristics, Localization Parameters and etc. 

The CDAI 14B will generate an InfoFrame for the User 
and Error Logs for the MDT Administrator in the local text. 
The User's local (and language) may not be the same as the 
Administrator's however. For this reason, the CDAI 14B 
may reference two Message Catalogs to collect localized 
text. The Native catalog will be used as a source for 
localized text for InfoFrames. The Error catalog will be used 
as a source of localized text for the Error Log. 

The text of the generated InfoFrame will be localizable. 
The localized names of Measures, Segments and Time 
Periods will be provided by the Client 12 or extracted from 
the Metadata, Other text will be kept as parameterized 
strings in an MDT Message Catalog. This is known as the 
Native catalog. The CDAI 14B will compute the name of the 
Native catalog from the value of the MsgCatalogPath 
attribute contained in the configuration file and the ISO 
language name provided by the client. A separate catalog 
must preferrably be kept to generate Error Logs in the MDT 
Administrators language. 

The CDAI 14B will accept one mdt_InfoFrameRequest 
object in an RUN_ANALYST_REQUEST message. The 
Request may contain an InfoFrame Definition (mdt_ 
InfoFrame Definition), describing the InfoFrame to be gen- 
erated. It may specify the type of the InfoFrame, the 
Segments) to be reported over, the Measure(s) to be 
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reported on and the Time Period(s) to report for. In one 
embodiment, there are five types of Reports. These are: 
Summarization — The basic analysis of a target measure 

over a target segment 
Change Analysis — Summarization of the difference of a 
target measure over two separate time periods and over 
a target segment 
Measure Comparison — Summarization of the difference 

between two measures over a target segment 
Segment Comparison — Comparison of the same measure 

over two separate target segments 
Trend Analysis — Report of trends over time in the target 
measure and related measures over the target segment 
and related segments 
The Request may contain an InfoFrame Trigger (mdt_ 
InfoFrameTrigger). The Trigger defines a test for some 
condition in the data warehouse 24 and an Alert flag and may 
contain a "nested" InfoFrame Request, If the Request con- 
tains a Trigger, the CDAI 14B must only implement the 
InfoFrame Definition if the condition is true. If the condition 
is true, the CDAI 14B must also, if the Alert flag is true, 
generate an Alert and, if the Trigger contains an nested 
Request, execute the nested Request. 

In general, the CDATs 14B output will be an InfoFrame 
object containing a localized, extended HTML Report (see 
FIG. 12). The InfoFrame will be written into a file in the 
User Return Area (defined below). 

The User Return Area is a directory whose path is given 
by the UserReturnAreaPath parameter fo the configuration 
file. On successful completion of the InfoFrame, the report 
will be named INF.<UID>.<UNQ> where UID is a User ID 
and UNQ is some string which guarantees that this file name 
will be unique from all other file names generated for this 
User. 

The Unique identifier will be generated by the Dispatcher 
when it launches the CDAI 14B and will make it available 
to the CDAI 14B with the InfoFrame request. As each 
Report requires a unique name, a CDAI 14B instance can 
only generate one Report. Where an InfoFrame Request 
specifies more than one report, when a triggered request 
requires an Alert Report and 'other' Reports as well as 'the' 
Report, the CDAI 14B accepting the request will need to 
dispatch new CDATs 14B to deal with this multitide of 
Reports. 

The HTML extensions used to build the Report are 
described in further detail in Ser. No. 08/742,003, filed Oct. 
31, 1996, and entitled "Hypertext Markup Language 
(HTML) Eextensions For Graphical Reporting Over An 
Internet" and assigned to NCR Corporation, also the 
assignee of the present invention and patent application. 
This Ser. No. 08/742,003, now U.S. Pat. No. 5,748,188, is 
incorporated herein by reference thereto. 

These extensions will be interpreted by the Client viewer. 
The Report will contain either an InfoFrame Report, an Alert 
Report or an Error Report. An InfoFrame Report will be 
generated when the CDAI 14B successfully completes an 
InfForame definition. It will be generated by the ifgn_ 
Report class. 

An Alert Report will be generated when an InfoFrame 
Request has a trigger and that trigger evaluates to true and 
the Alert flag is set. It will be generated by the ifgn_ 
AlertFrame class. 

An Error Frame will be generated when the CDAI 14B is 
unable to evaluate a trigger or an InfoFrame definition and 

lives to tell about it. It will be generated by the ifgn 

ErrorFrame class. 
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The content of the InfoFrame Report (see FIG. 12) is 
highly variable, depending not only on the type of analysis 
required but on the values of the measures encountered. The 
Report may be organized in a variety of ways, such as a 
heading, four bulleted paragraphs, a table, etc. For example: 
Heading — Quotes the Analyst Description provided by 
the User when the Analyst is defined and names the 
Segments, Measures and Time Periods analysed and, if 
the Analyst had a trigger, the trigger terms and the time 
at which the trigger condition was satisfied. 
Target Segments) Report — A bulleted paragraph which 
contains: 

Target Segments — Text highlighting the results for the 
measures) over the segment(s) and time period(s) 
directly specified in the analyst definition. Additional 
measures are not reported in this section. 

Parent Contribution — A bulleted paragraph highlighting 
any significant contribution made by the target segment 
(s) to its parent segment. This section is not included 
when the target segments) is a top level segment or if 
the target measure(s) contains a reference to a parent 
segment. 

Sibling Comparison — A bulleted paragraph offering inter- 
esting comparisons of the target segments)' value to 
the values of its sibling segments. This section is not 
included when the target segments) is a top level 
segment. 

Sibling Graphs — A bar or pie chart showing the values of 
the sibling segments or a Line graph showing trends. 
This graph is not produced if there are Drill Down 
segments. 

Drill Down — A bulleted paragraph highlighting interest- 
ing relationships between the values of child segments 
in the drill down partitions) to the value for the target 
segment. Drill Down partitions may be specified by the 
user in the analyst definition. If the user does not 
specify any drill down partitions, MDT automatically 
chooses one or more interesting partitions. See the 
section below on choosing drill down partitions to learn 
how they are automatically chosen. This section is not 
included when no child partition exists and no unre- 
stricted attributes exist to create or if no existing or 
created partition is interesting. 

Drill Down Graph — A bar or pie chart showing the values 
for the Drill Down Sements or a Line chart showing 
trends. This graph is not produced if there are no 
interesting Drill Down segments. 

Formula Decomposition — A bulleted paragraph high- 
lighting interesting contributions to the composite mea- 
sure of its component measures. This section is 
included only when the target measure is a composite 
measure. 

Measure Relationships — A bulleted paragraph describing 
possible causes for the difference between two values 
of the target measure (or the difference between the 
target and comparison measures for the Measure Com- 
parison Analysis). The Summarization Analyis will not 
contain a Measure Relations paragraph. 
Table 

A table showing all the measure values reported during 
the analysis 

Segments other than the Parent, Target or Comparison 
segment may be marked as hyperlinks (see again, e.g., FIG. 
12). The underlying HREF will contain the information 
required to substitute this segment as the target segment for 
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a new analyst of the same type, for the same measure, 
comparisons and periods. 

The Alert Report is much more straight forward. It's most 
interesting characteristic is the hyperlink to the Analyst 
Name. When the Info Frame Request was denned, an Anal- 
syst may have been defined to optionally gather more 
information on the event. By selecting the hyperlink, the 
User can launch this Analyst. The text of the Alert frame 
may look like: 



Alert: <Analyst Name> 
<Tkrget Segment> 
<Additional Segment 1> 

<Additiona] Segment n> 

<Base Time Period Description 

Alert was triggered at <time alert triggered* 

Click here to run <Analyst Namonow. 

Trigger is: <Measure Name>[<Operator><Measure Namo], 
<Measure Name>[<Operator><Measure Name>]. 

^Measure Name>[<Operator><Measure Name>] 



An Error Report may be simpler still. It is meant to 
communicate exactly one statement to the User 1405, a 
description of the error encountered. The format may be: 



Error: <AnaIyst Name> 

An Error Occurred at <time error occurred* 

<Error Test> 



The CDAI 14B may report errors to a server error log. The 
texts of the error messages are maintained in the error 
message catalog as parameterized, localizable strings. 
4. DSM Subsystem 16 and Scheduler Subsystem 18 

The data and schema manipulation subsystem 16 and 
scheduler subsystem 18 are described in further detail below. 

The MDT Server 32 may implement two classes of 
Requests for the User 1405. 

Interactive Requests; Metadata Fetch, Metadata Update, 
InfoFrame Scheduling, InfoFrame Status and etc. The 
Server will implement one Interactive Request at a time 
for each Client. That we handle one Interactive Request 
at a time is almost as interesting as that they are 
interactive so we will also call these Serial Requests. 
Batch Requests; Trigger Requests and InfoFrame Gen- 
eration. The Server must be able to implement multiple 
Batch Requests at a time. That we must handle multiple 
Batch Requests at a time is almost as interesting as that 
they are batch so we will also call these Concurrent 
Requests. 

Each Concurrent Request will cause one or more queries 
against the Database. The ODBC standard supports asyn- 
chronous queries against the database but many implemen- 
tations of ODBC do not. In these implementations, each 
Concurrent Request will require its own process. Because 
putting each Request in its own process allows us to work 
with many more ODBC implementations and passes respon- 
sibility for managing the memory and data structures for 
multiple Requests to the operating system, each Concurrent 
Request will be get its own process. This process will be the 
Concurrent instance. 

If Serial Requests and returning results are made to be 
asynchronous events, a single Server instance might be able 
to handle all of the Server's Serial Requests. But imple- 
menting asynchronously, while not overly difficult, is rather 
pointless when each Client 12 can simply be handed a new 
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Server instance. Each Client 12 is therefore assigned a Serial 
instance to handle its Interactive Requests. 

Its important to note that Windows NT implements 
threads, and future revisions of the UNIX operating system 
5 should as well. Threads provide an opportunity to pass 
responsibility for handling asynchronous events to the oper- 
ating system while still managing memory in a single 
process. 

Also, for purposes of the present invention description, it 
will be assumed that the Serial and Concurrent instances will 
be implemented by unique executables, each implementing 
a subset of complete Server functionality appropriate to its 
Requests. 

With reference to FIG. 25, the Server 32 may be imple- 
mented as a collection of cooperating processes. There will 
be five classes of processes, as described below: 
The Master process 2511, responsible for accepting Client 
connections with the Server and assign the Client 12 a 
Serial instance. 

2 0 The Serial instance 2512, responsible for executing all of 
this Clients Serial Requests. These will be Metadata 
Fetches and Updates, InfoFrame Scheduling Requests 
and etc. The Serial instance will queue Scheduled 
InfoFrame Requests in the Scheduler's Queue. The 

25 Serial instance will also get the Client's InfoFrame 
Generation Requests, a Concurrent Request, but it will 
pass this on the Dispatcher. 
The Dispatcher process 2513, responsible for assigning a 
Concurrent instance to each Concurrent Request passed 

30 to it by the Serial instance or the Scheduler and for 
reporting the state of pending and executing Concurrent 
Requests. 

The Concurrent instance 2514, responsible for executing 
a single Concurrent Request. 
35 The Scheduler processes 18, responsible for passing 
InfoFrame Requests to the Dispatcher at the scheduled 
time. 

Create relationships are indicated with white pointers 
2501 from parent to child. Request relationships are indi- 

40 cated with black arrows 2502 from sender to recipient, 
A process of the Server will share several resources in 
common to present a single state to the client. These are the 
Metadata, the Scheduler Queue and the Return Area. 
When a User 1405 makes a change to the Us er's 

45 MrTadata , tha t change must be~visible to all_of theUs er's 
slif^ a ^ntJnfoFrame Requests. W h en that User 1405 is t he 
M lVlA (Administrator) and the MDTA specifies chan ges to 
gl obal Metadata, these change s must be visible to all sub- 
se quent Requests. ~ 

50 ^MDT's Metadata will be stored on the Customer's Data 
Warehouse 24. Accesses to this Metadata will be managed 
by the DSM 16. In order to optimize accesses to the 
Metadata, the DSM 16 will implement a shared memory, 
write through cache of the MDT tables. 

55 Each User 1405 will use only a subset of Metadata, and 
for practical reasons that data will be re-organized from flat 
tables of the database into an application specific structure. 
Each of the User's Serial and Concurrent instances 2512, 
2514 will need to keep a copy of this subset. This image will 

so be constructed and maintained by the DAI 14. 

When a User IdnS-w ^ rijfje s a Metadata i tem, the DAI 1 4 
wilfefifecj ^exfiange to the local un a ge'and' will comm and 
t he DSM frTit update the data wareKouse 24. ThejjSM 16 
will write this change into the shared memory cache a nd 

65 trirq ugh the cache to the warehouse 24T~ 

The relationships and operations on Metadata are illus- 
trated schematically in FIG. 26. The light arrows 2601 
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represent attachments to the shared memory Metadata Cache 
2610. The bold arrows 2602 represent the path of Metadata. 

The present MDT invention will maintain a single Sched- 
uler Queue which will list all of the InfoFrame Requests 
scheduled to execute at some future time or to execute at 
regular intervals. 

Wh^q f hft User 1405 schedules an InfoFrame Reques t 
through the Client 12, the Schedule Request will be passed 
t hrough the Serial instance 2512 to the Scheduler 18, The 
Scheduler 18 will accept tde Request and will place the 
Request in the Schedule Queue. When the User 1405 deletes 
a Scheduled Request the Scheduler 18 will delete the 
Request from the Scheduler Queue. The DAI 14 will also 
accept a User's Schedule Status Requests. It will satisfy 
them by inspection of the Scheduler Queue. 

At regular intervals, the Scheduler 18 will inspect the 
Scheduler Queue, will identify Requests that have come due 
and will pass them to the Dispatcher 2513. The Scheduler 18 
will then remove non-recurring Requests from the Scheduler 
Queue. 

The Dispatcher 2513 will create a Concurrent instance 
2514 to execute the Requests. A Concurrent instance 2514 is 
a process and expect processes should be a limited resource 
which must be managed by the Dispatcher 2513. Thus, an 
InfoFrame Request passed to the Dispatcher 2513 may exist 
in one of two states: (1) pending (waiting for a process) and 
(2) Executing. The Dispatcher 2513 will keep a list of 
Pending and Executing Requests. When the User 1405 
makes an InfoFrame Status Request, the Client 12 will pass 
it to the Serial instance 2512 and the DAI 14 will implement 
it. It will need to collect the list of the User's Request status 
from the Dispatcher 2513 to complete the Status Request. 

The relationships and operations on the Scheduler Queue 
2710 are illustrated schematically in FIG. 27. The path of the 
InfoFrame Request is represented by the black arrows 2701. 
Status Information regarding scheduled Requests and Pend- 
ing or Executing Requests, which must be collected by the 
Serial instance in response to the Client's status Requests, is 
represented by White arrows 2702. 

Completed InfoFrames will be parked in the Return Area 
between the time they are completed and the time the Client 
12 calls to collect them. The Return Area is simply a 
directory on the file system. It will contain a sub-directory 
for each user 1405. 

When the Concurrent instance 2514 completes an InfoF- 
rame Request it will copy the InfoFrame into the User's 
sub-directory of the Return Area. Recurrent Requests may 
leave many InfoFrames in the Return Area. The Concurrent 
instance 2514 must generate unique names for each Report. 

The Client 12 will occasionally pass InfoFrame Status 
Requests to the Serial instance 2512. The DAI 14 will 
implement the Request. The DAI 14 will need to inspect the 
User's sub-directory of the Return Area to identify the 
InfoFrames that have been completed. The DAI 14 might 
'decode* the file names to produce Analyst names and 
execution dates to report to the Client 12. 

The Client 12 will also occasionally pass InfoFrame 
Upload Requests to the Serial instance 2512. The DAI 14 
will implement the Request. The DAI 14 will collect the 
InfoFrame from the User's sub-directory of the Return Area. 
It will pass the InfoFrame to the Client 12 and will remove 
the image from the Return Area when the Client 12 acknowl- 
edges receipt. 

The relationships and operations on the Return Area 2810 
are illustrated schematically in FIG. 28. The flow of the 
completed InfoFrame is represented by the black arrow 
2801. The movement of status required by the Serial 
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instance 2512 to satisfy a Client Status Request is repre- 
sented by the white arrow 2802. 

1. DSM Subsystem 16 

The DSM Subsystem 16 is described in further detail 
5 below. 

The SQL Generator receives a Dimensional Query from 
the InfoFrame Generator, generates the necessary database 
queries, and returns the results to the InfoFrame Generator. 
The interface to the database is through ODBC, which takes 

10 queries in the form of SQL strings. 

The SQL Generator must query the database 24 to evalu- 
ate each Measure/Segment pair. The Measures may be from 
the daL_MeasureList. In the first form of QueryDatabase( ), 
the segments are the child segments of the targetPartition; in 

15 the second form, each Measure is evaluated only for the 
implied target segment. Each of the measures may be a 
Composite Measure, which may require multiple queries to 
evaluate the Measures that make up the Composite Measure. 
Standard SQL programming techniques may be used to 

20 implement the DSM Subsystem 16. 

2. Scheduler Subsystem 18 

The scheduler subsystem 18 is described in further detail 
below. 

The scheduler subsystem 18 is responsible for submitting 
25 Analysts with schedules and/or triggers to be run. It is also 
responsible for maintaining lists of scheduled and/or trig- 
gered Analysts; deleting, modifying and adding to those 
lists. 

In this section, an Analyst which has a schedule, a trigger, 
30 or a schedule and a trigger will be referred to as a 'sched- 
uled' Analyst unless there is a difference in the way the three 
types of Analysts behave. 

When an InfoFrame request is received by the S-DAI 
subsystem 14A, it will be passed to the Scheduler subsystem 
35 18 if it is associated with a scheduled Analyst . The Scheduler 
18 will determine the proper time period in which to 
dispatch the Analyst. When it is scheduled to run, a request 
will be passed to the dispatcher 2513 as in the same manner 
that the S-DAI subsystem 14A passes non-scheduled 
40 requests. 

FIG. 29 illustrates this process in further detail. 
From the S-DAI 14A, the Scheduler 18 will receive 
scheduled InfoFrame requests, delete and disable user 
requests, delete scheduled Analyst requests. To uniquely 
45 identify requests, the S-DAI 14A must provide an Analyst id 
(contained in the InfoFrame request object) and a user id. 

When a scheduled InfoFrame request is received, the 
Analyst is placed on the Trigger List 2901 if the Analyst has 
a trigger, or the Schedule List 2902 if it has either a schedule 
50 or a schedule and a trigger. The difference between a 
triggered Analyst and a scheduled, triggered Analyst is that 
the former is run at each trigger period while the latter is run 
only when scheduled. 
The Scheduler 18 has two execution time periods, one for 
55 triggered requests and one for scheduled requests. The two 
time periods are configurable on each MDT server 32 and 
may be changed by the MDT Administrator. 

When the trigger time period occurs, the Scheduler 18 
traverses its list 2901 of triggered events. For those sched- 
60 uled to run during that time slice and whose user account is 
enabled, a copy of the InfoFrame request without the trigger 
is passed to the Dispatcher 2513. An analogous process is 
followed for the schedule time period and schedule list 2902. 
If a user 1405 is deleted, the Scheduler 18 will remove any 
65 Analysts from the lists which are owned by the deleted user. 
If a user 1405 is disabled, any Analysts on the lists will not 
run until the user 1405 is once again enabled. If an Analyst 
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is modified, the user 1405 must explicitly remove any 
associated scheduled requests or they will continue to run 
with the old Analyst definition. 

Although the present invention has been described with 
particular reference to certain preferred embodiments 
thereof, variations and modifications of the present inven- 
tion can be effected within the spirit and scope of the 
following claims. 

What is claimed is: 

1. A system for managing a database hierarchy, compris- 
ing: 

(a) a database computer, including a data warehouse 
comprising data entities having associated attributes, 
wherein the data entities are arranged in a first 
hierarchy, each level of the first hierarchy being asso- 
ciated with at least one attribute; 

(b) a server computer coupled to the database computer, 
wherein the server computer includes a data abstraction 
intelligence subsystem and a data and schema manipu- 
lation subsystem having: 

(1) means for receiving an attribute restriction value for 
restricting a selected attribute; and 

(2) means for partitioning and segmenting the database, 
wherein a second hierarchy is created, the second 
hierarchy being associated with the attribute restric- 
tion value; and 

(c) a client computer coupled to the server computer, 
wherein the client computer includes: 

(1) means for inputting from a user of the client 
computer the attribute restriction value; and 

(2) means for transmitting the attribute restriction value 
to the receiving means of the data abstraction intel- 
ligence subsystem and the data and schema manipu- 
lation subsystem. 

2. The system of claim 1, wherein the data abstraction 
intelligence subsystem and the data and schema manipula- 
tion subsystem further include means for transmitting the 
second hierarchy to the client computer, and the client 
computer further includes means for receiving the second 
hierarchy from the data abstraction intelligence subsystem 
and the data and schema manipulation subsystem and dis- 
playing the second hierarchy to the user of the client 
computer. 

3. The system of claim 1, wherein the data abstraction 
intelligence subsystem and the data and schema manipula- 
tion subsystem further include means for querying the data 
entities within the database having the first hierarchy. 

4. The system of claim 1, wherein the data abstraction 
intelligence subsystem and the data and schema manipula- 
tion subsystem further include means for querying the data 
entities within the database having the second hierarchy. 

5. The system of claim 1, wherein the data abstraction 
intelligence subsystem and the data and schema manipula- 
tion subsystem further include means for querying the 
database. 

6. The system of claim 5, wherein the querying means 
comprises a SQL server. 

7. The system of claim 5, wherein the client computer 
further includes means for transmitting a query request to 
the querying means. 

8. In a computer system comprising a client computer, a 
server computer coupled to the client computer, and a 



ao 



15 



20 



25 



30 



35 



45 



50 



55 



60 



database coupled to the server computer, wherein the data- 
base contains data entities, and wherein the server computer 
includes a data abstraction intelligence subsystem and a data 
and schema manipulation subsystem, a process for manag- 
ing a hierarchy associated with the database, comprising the 
steps of: 

(a) associating attributes with the data entities; 

(b) arranging the data entities in a first hierarchy, wherein 
each level of the first hierarchy is associated with at 
least one attribute; 

(c) inputting from a user of the client computer an 
attribute restriction value; 

(d) transmitting the attribute restriction value from the 
client computer to the data abstraction intelligence 
subsystem and the data and schema manipulation 
subsystem, the attribute restriction value restricting a 
selected attribute; and 

(e) segmenting the database, wherein a second hierarchy 
is created, the second hierarchy being associated with 
the attribute restriction value. 

9. A system for managing a database, comprising: 

(a) a hierarchical database comprising data arranged in 
tables having columns; 

(b) a server computer coupled to the database, the server 
computer including a data abstraction intelligence sub- 
system and a data and schema manipulation subsystem; 

(c) a client computer coupled to the server computer, the 
client computer including means for receiving input 
from a user of the client computer, 

wherein the system creates metadata concerning a particular 
business for use in partitioning and segmenting the database, 
the metadata being created by the following method: 

(1) receiving as an input from the user a specified business 
concept; 

(2) receiving as an input from the user one or more 
attributes for the specified business concept; 

(3) providing to the user a list of columns of tables in the 
database; 

(4) receiving as an input from the user a mapping of each 
attribute to a column in a table in the database. 

10. Asystem according to the claim 9, wherein the method 
for creating metadata includes the following additional 
steps: 

(5) receiving as an input from the user one or more 
business indicators; 

(6) providing to the user a list of columns of table in the 
database; 

(7) receiving as an input from the user a mapping of each 
business indicator to a column in a table in the data- 
base; 

(8) receiving as an input from the user an aggregate 
method for the mapped business indicators; 

(9) receiving as an input from the user a selected unit of 
measurement for the mapped business indicators; 

(10) ensuring that tables having mapped business indica- 
tor columns can be joined with tables having mapped 
business attribute columns. 
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